85  ftfi  24  ft02 


security  classification  or  this  pace  rm»*«  d«(«  &* *«r«o 


j  REPORT  DOCUMENTATION  PAGE 

R£AD  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

|  1,  REPORT  NUMBER 

L .  _ 

2. 

A 

GOVT  ACCESSION  NO. 

PA  i  A  (? 

S.  RECIPIENT'S  CATALOG  HOMIER 

7(t . 

4.  TITLE  <md  Submit) 

Shipboard  Non~Tactica.l  Computer  Systems 
of  the  CJ .  S  .  Navy 

s.  type  of  report  s  period  covered 

Master's  Thesis 

March  1985 

«.  PERFORMING  ORG.  REPORT  NUMBER 

7.  AUTHORfn> 

William  J.  McMican  and 

James  J.  Richards 

(.  CONTRACT  OR  GRANT  NUMBKRf.J 

S  PERFORMING  ORGANIZATION  NAME  AND  ADDRESS 

Naval  Postgraduate  School 

Monterey,  CA  93943 

10.  PROGRAM  ELEMENT.  PROJECT,  TASK 
AREA  *  WORK  UNIT  NUMBERS 

II.  CONTROLLING  OFFICE  NAME  AND  ADDRESS 

Naval  Postgraduate  School 

Monterey,  CA  93943 

12.  REPORT  DATE 

March  1985 

IS.  NUMBER  of  pages 

129 

14.  MONITORING  AGENCY  NAME  A  AOORESV'f  dlllttmnt  from  Csnfroll/nj  OlllCb) 

IS,  SECURITY  CLASS,  (of  thlm  report) 

UNCLASSIFIED 

Me.  OECL  ASSiFlCATlON'  DOWNGRADING 
SCHEDULE 

DISTRIBUTION  STATEMENT  'ot  Nil.  Ktpen) 

APPROVED  FOR  PUBLIC  RELEASE; 

DISTRIBUTION  IS  UNLIMITED 

'7.  DISTRIBUTION  STATEMENT  (of  the  ebetrmct  entered  In  Block  30,  If  different  from  Report) 

IS.  supplementary  notes 

19-  KEY  WORDS  (Continue  on  reverte  tide  it  neceeemry  end  Identify  by  black  number) 

SNAP,  Non-tactical,  computer,  PERQ ,  ZOG,  Shipboard,  Wang-Net 

20  ABSTRACT  (Continue  on  r*v«>«  jM*  If  nacemcary  mtd  Identify  by  block  number) 


This  thesis  reviews  the  development  and  application  of  current 
non-tactical  shipboard  ADP  systems  in  the  U.S.  Navy,  and  provides 
an  analysis  of  each  systems'  strengths  and  weaknesses.  The 
primary  focus  of  this  review  includes  PERQ/ZOG,  WANG  installa¬ 
tions,  and  SNAP  II  System.  The  methodologies  of  procurement, 
development  and  implementation  vary  as  widely  as  the  scope  and 
complexity  of  the  various  systems.  This  analysis  provides 
insight  into  some  primary  management  (Continued) 

DO  i  jam*?)  1473  coition  or  i  nov  «i  is  obsolete 

S/N  0102-  UF-0U-460I 


X  iCCUNITY  CLASSIFICATION  OF  THIS  RACE  fWipn  Dtt*  Cnlwxr; 


SBCUKITT  CLASSIFICATION  OF  THIS  PAOC  Balm  EntmD 


S  H  0102-  LF-  014  -  6601 


Approved  for  public  release;  distribution  is  unlimited. 


Shipboard  Non-tactical  Computer  Systems 
of  the 
U. S .  Navy 

by 

William  J.  McMican 

Lieutenant  Commander,  SC,  United  States  Navy 
B.S.  United  States  Naval  Academy,  1972 

and 

James  J.  Richards 

Lieutenant  Commander,  United  States  Navy 
B.A.  Wayne  State  University,  1971 


Submitted  in  partial  fulfillment  of  the 
requirements  for  the  degree  of 

MASTER  OF  SCIENCE  IN  INFORMATION  SYSTEMS 

from  the 

NAVAL  POSTGRADUATE  SCHOOL 
March  1985 


LJ'G'ix  /I  y) 

~  ~ wi Ills  RC  Greer ,  Chairman, 

Department  of  Administrative  Sciences 

yc.  _ 

nneaie  Tt-  lHarsnanr+>> 

Dean  of  Information  and  Policy  Sciences 


/ 


ABSTRACT 


V  \ 

This  thesis  reviews  the  development  and  application  of 
current  non- tactical  shipboard  ADP  systems  in  the  U.S.  Navy, 
and  provides  an  analysis  of  each  systems'  strengths  and 
weaknesses.  The  primary  focus  of  this  review  includes 
Perq/ZOG,  WANG  installations,  and  SNAP  II.  The 

methodologies  of  procurement,  development  and  implemenation 
vary  as  widely  as  the  scope  and  complexity  of  the  various 
systems.  This  analysis  provides  insight  into  some  primary 
managemet t  issues,  limitations,  and  constraits  encountered 
in  providing  non-tactical  automatic  data  processing  to  the 

fleet.  i/. -5T —  V 
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I.  INTRODUCTION 


"For  want  of  a  nail  the  shoe  is  lost,  for  want  of  a  shoe 
the  horse  is  lost,  for  want  of  a  horse  the  rider  is 
lost1'.  [Ref.  1] 


These  familiar  words  from  an  old  verse  still  ring  true 
today,  except  with  the  U.S.  Navy,  the  proverbial  nail  has 
been  replaced  by  the  small,  modern,  non- tactical  computer. 

Since  the  late  1970' 3,  there  has  been  a  proliferation  of 
computers  on  board  the  ships  and  vessels  of  the  U.S.  Navy, 
which  has  served  to  revolutionize  the  'processing  of 
information  at  sea  These  small  processers  have  generally 
increased  the  productivity  of  ship's  administrative 
personnel  by  allowing  each  man  to  produce  more  information 
of  a  higher  quality  than  was  previously  possible  in  a  manual 

_ _ s_  mi - -  1 - —  _  i _ _ ’ _ j _ a  i_i _ /•*  — _ _ j  :  _ _  Ar  r  j _ _ a  — 

a  it,/ vac:  .  mcy  uavc  aiau  j^auviucu  uic  uujuiiiciiivxx  HL4  vax.JLJ.uc3i.  cn  rtx  iij.o 

key  assistants  with  more  timely  information  on  which  to  base 
their  everyday  management  decisions. 

Along  with  these  benefits,  the  introduction  of  the  small 
non-tactical  computer  into  the  shipboard  environment  has 
exacerbated  the  ongoing  concerns  of  security  and 
standardization,  while  introducing  many  new  issues  that  must 
be  dealt  with,  such  as  control  of  computer  resources  and 
dependency  on  systems  that  could  cease  to  function  at  any 
time  in  the  harsh  at-sea  environment  of  a  ship. 

The  objective  of  this  thesis  is  not  to  identify  and 
analyze  all  the  systems  presently  implemented  on  board  Naval 
ships,  but  to  survey  a  few  of  them  in  regards  to  their 
architecture,  benefits,  and  unique  technical  and  managerial 
problems . 

This  thesis  focuses  on  three  distinct  computer 
installations  that  are  currently  implemented  on  board  U.S. 
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Naval  ships.  Chapter  Two  looks  at  a  system  of  Perq 
minicomputers  installed  on  board  the  U.S.S.  Carl  Vinson  that 
run  an  experimental  menu-driven,  distributed  database  called 
ZOG .  ZOG  was  developed  at  Carnegie-  Mellon  University  with 
support  .from  both  the  Office  of  Naval  Research  (ONR)  and  the 
Defense  Advanced  Research  Agency  (DARPA) .  Chapter  Three 
addresses  the  WANG  VS-100  which  is  also  installed  on  board 
the  U.S.S.  Carl  Vinson.  It  was  selected  for  inclusion  in 
this  thesis  because  it  is  an  off-the-shelf  commercial  system 
that  has  been  installed  and  operated  without  being 
specifically  designed  or  altered  for  the  shipboard 
environment.  This  system  was  also  developed  without  the 
benefit  of  government  support.  Chapter  Four  discusses  the 
SNAP  system,  which  is  presently  being  placed  on  board  all 
naval  ships.  This  system  comes  in  two  versions,  the 
Honeywell  SNAP  I  system  is  for  large  ships,  and  the  Harris 
SNAP  II  system  is  for  smaller  ones.  Both  of  Chests  systems, 
which  are  centrally  procured  and  managed  by  the  Navy,  have 
been  specifically  ruggedized  for  a  shipboard  environment. 
Chapter  Five  consolidates  some  of  the  conclusions  that  have 
been  drawn  from  the  other  chapters. 

While  this  thesis  does  not  attempt  to  analyze  the  whole 
spectrum  of  problems  concerning  lion-tactical  automation  that 
is  now  being  addressed  in  the  fleet,  it  does  attempt  to 
survey  many  of  them  from  the  viewpoint  of  the  professional 
naval  officer.  However,  a  concerted  effort  has  been  made 
to  define  or  describe  terms  unique  to  the  Navy  or  shipboard 
life  for  those  readers  without  an  appropriate  naval 
background. 
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II .  PER Q 


A.  INTRODUCTION 

In  1981,  a  non-tactical  computer  system  consisting  of 
twenty-eight  Perq  minicomputers  and  the  prototype  software 
called  ZOG  was  installed  on  board  the  Navy’s  new  aircraft 
carrier,  the  U.S.S.  CARL  VINSON.  These  minicomputers  were 
state-of-the  art  technology,  offering  the  user  a  choice 
between  mouse  technology  or  a  detachable  keyboard  for 
accessing  the  ZOG  system.  Each  Perq  minicomputer  was  also 
configured  with  a  hardware  graphics  tablet  for  the  mouse, 
one  megabyte  of  random  access  memory,  four  thousand  byte3  of 
writable  control  storage,  and  a  twenty-four  megabyte 
Winchester  hard  disk  storage  drive.  All  the  Perq 
minicomputers  were  connected  in  a  local  area  network  by  a 
lOmz  Ethernet. 

The  heart  of  this  system  was  ZOG,  an  experimental, 
human-computer  interface  conceived  and  developed  at 
Carnegie-Mellon  University  in  the  early  1970's.  It  is  the 
transfer  of  ZOG  technology  from  the  research  laboratory  of 
academe  to  the  operational  shipboard  environment  of  the 
U.S.S.  CARL  VINSON  t1-— t  will  be  the  focus  of  this  chapter. 

B .  BACKGROUND 

ZOG  was  initially  conceived  and  developed  in  1972  as 
part  of  a  summer  workshop  held  at  Carnegie-Mel Ion  University 
( CMU )  for  cognitive  psychologists  studying  simulation 
[Ref.  2].  The  original  intent  of  ZOG  was  to  provide  a 
system  that  would  allow  new  users  to  access  and  explore 
large  complex  programs.  Although  the  concept  proved 
workable,  lack  of  a  fast  terminal  input/output  device  made 
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the  actual  system  too  slow.  At  that  time,  state  of  the  art 
terminal  technology  was  limited  to  300  baud  with  hardcopy 
output.  Hence,  the  system  was  shelved  until  more  advanced 
hardware  and  communication  technology  became  available. 

In  1975  Alan  Newell  and  George  Robertson,  two  of  the 
original  developers  of  SOG,  served  on  a  technical  advisory 
committee  for  PROMIS  (Problem  Oriented  Medical  Information 
System);  a  system  strikingly  similar  to  the  SOG  concept,  but 
which  utilized  the  latest  in  hardware  technology.  PROMIS  was 
conceived  by  DR.  Lawrence  Weed  of  the  University  of  Vermont 
Medical  School.  It  was  a  combination  of  a  management 
information  system  and  a  menu  guidance  system  that  was 
billed  as  a  comprehensive  approach  to  health  care.  [Ref.  3] 
PROMIS  used  a  Sperry-Univac  V77-600  minicomputer  with  250k 
ram,  three  Control  Data  Corporation  Storage  Module  Drives  ( 
250  megacharacters  per  spindle  )  and  associated  peripherals 
per  node.  The  user  interfaced  the  computer  via  a  high  speed 
(  approximately  1/2  second  access  time)  CRT  terminal,  which 
incorporated  a  touch  sensitive  screen  as  well  as  a  standard 
keyboard  [Ref.  4]  . 

This  demonstrated  use  of  modern  high  speed  terminal 
technology  in  the  PROMIS  system  resulted  in  revived  interest 
in  ZOG  at  Carnegie-Mellon  University.  With  support  from  both 
the  Office  of  Naval  Research  (ONR)  and  the  Defense  Advanced 
Research  Agency  (DARPA),  newer  versions  of  ZOG  were 
developed  and  brought  up  on  the  university's  PDP-10,  first 
using  a  Tops  10  and  then  a  TOPS  20  operating  system.  ZOG  was 
also  installed  on  the  university's  experimental 
multiprocessor,  C.MMP.  By  1980  Carnegie-Mel .  asearchers 
were  successfully  running  ZOG  on  a  new  Eti  local  area 
network,  which  connected  the  university' 3  '•  Or,  Xerox 
Altos,  and  new  DEC  Vax  computers.  [Ref.  5] 

There  were  two  occurrences  in  1980  that  had  major  impact 
on  ZOG' s  development.  One  was  the  implementation  of  SPICE, 
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(Scientific  Personal  Integrated  Computing  Environment)  as  a 
research  project,  at  Carnegie-Mellon.  Since  several  of  the 
researchers  working  on  SPICE  had  also  worked  on  ZOG,  it  was 
inevitable  that  the  two  systems  would  be  closely  affiliated. 
Informal  relationships  that  occurred  because  of  this  close 
affiliation  were  reinforced  as  a  result  of  a  conscious 
decision  made  by  researchers  at  Carnegie-Mellon  to 
eventually  integrate  all  software  projects  at  the  university 
with  SPICE.  As  a  direct  result  of  this  decision,  the  Perq 
minicomputer  from  the  Three  Rivers  Computer  Corporation  that 
was  selected  for  initial  SPICE  implementation,  was 
ultimately  selected  for  ZOG  when  it  was  moved  from  the 
research  to*  the  operational  arena.  [Ref.  6] 

The  other  occurrence  was  a  visit  to  Carnegie-Mellon  by 
Navy  Captain  Richard  Martin,  the  prospective  commanding 
officer  of  the  nuclear  powered  aircraft  carrier,  U.S.S. 
CARL  VINSON,  then  under  construction  in  Newport  News, 
Virginia. 

Captain  Martin  was  visiting  several  ONR  research  sites 
throughout  the  country  to  familiarize  himself  with  the 
latest  developments  in  various  technical  areas.  Kis  purpose 
at  Carnegie-Mellon  was  to  ascertain  what  advanced  computer 
technology  was  available  that  might  prove  useful  on  board 
the  U.S.S  CARL  VINSON.  His  initial  encounter  with  ZOG  at 
Carnegie-Mellon  convinced  Captain  Martin  that  a  marriage 
between  the  new  software  technology  and  the  U.S.S.  CARL 
VINSON  would  serve  two  purposes. 

1.  It  would  supply  the  ONR/'DARPA  supported  research  at 
CMU  with  an  operational  test  bed,  and 

2.  It  would  give  U.S.S  CARL  VINSON  the  latest  in 
computer  technology  to  help  manage  the  carrier's 
extensive  administration  requirements  in  the  areas  of 
management,  maintenance,  and  planning. 
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To  evolve  ZOG  to  a  point  where  it  could  be  implemented 
on  board  U.S.S.  CARL  VINSON,  a  formal  ZOG  Technological 
Demonstration  Project  was  established  in  March  19S1 .  Its 
goals  were  to  get  fleet  personnel  involved  as  soon  as 
possible  in  the  ZOG  project,  to  accelerate  application 
development  to  more  closely  conform  with  U.S.S  CARL  VINSON's 
commissioning  and  trial  schedules,  and  to  expand  the 
functional  span  and  quality  of  the  final  product  [Ref.  7]. 
Three  shipboard  areas  were  initially  selected  to  use  ZOG. 
These  included  on-line  creation  of  the  Ship's  Organization 
and  Regulations  Manual  (SORM),  administration  planning  and 
evaluation,  and  weapons  elevator  maintenance  training. 

C.  THE  NATURE  OF  ZOG 

Thus  far,  we  have  only  briefly  described  the  evolution 
of  the  Perq/ZOG  system  from  its  beginnings  at 
Carnegie-Mellon  University  in  the  early  seventies,  to  the 
establishment  of  a  formal  ZOG  Technological  Project  in  March 
1981.  We  have  not  specifically  defined  nor  completely 
described  ZOG.  What  is  ZOG?  How  does  it  differ  from  the 
numerous  other  software  concepts  that  were  being  discussed 
and  developed  in  universities,  research  institutions,  and 
commercial  laboratories  throughout  the  1970' s  and  early 
1980's?  These  and  similar  type  issues  must  be  discussed 
before  ZOG's  potential  impact  can  be  analyzed  and  evaluated. 

1 •  Essence  of  ZOG 

ZOG  has  been  described  as  "a  rapid-response, 
large-network,  menu- selection  computer  interface”  [Ref.  8]. 
In  less  succinct  words,  it  is  an  extremely  fast,  distributed 
data-base  that  is  driven  by  menus  called  display  frames. 
These  display  frames  are  the  essence  of  ZOG.  The  function  of 
a  display  frame  is  to  present  information  to  the  user  and 
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allow  him  to  jump  to  another  frame  when  finished  with  the 
one  he  is  currently  on.  With  few  exceptions,  the  degree  of 
information  that  can  fit  on  the  standard  terminal  screen  is 
the  maximum  amount  of  information  allowed  in  one  display 
frame.  This  limitation  does  not  present  many  problems, 
however.  Since  the  Perq's  high  resolution  screen  actually 
allows  two  full  frame  menus  to  be  displayed  at  a  time,  the 
user  does  not  require  a  scrolling  function  when  viewing 
data.  The  first  information  item  on  a  display  frame  is  the 
frame's  title  line.  It  can  consist  of  a  variable  length 
title  and  a  short  summary  of  the  frame's  contents.  The 
second  information  item  is  the  frame's  text.  It  further 
expounds  on  the  frame's  main  point  of  information.  The  third 
inf cri«stici*  section  consl-itu.'tss  3.  of  nv.rp^sirsci  options. 
An  option  can  consist  of  the  title  of  a  subsequent  frame, 
which  when  activated  will  move  the  user  to  that  particular 
frame.  Options  can  also  be  used  like  subpoints  of  the  frame 
text  £.3  in  an  outline  [Ref.  9],  If  we  envision  the  entire 
database  as  a  tree  structure,  and  each  menu  as  a  parent 
node,  we  can  view  the  children  of  each  parent  node  as  frames 
accessible  through  options.  A  fourth  information  item  cn  the 
frame  is  the  set  of  local  pads.  Local  pads  are  used  to 
invoke  programs  or  point  to  extrinsic  information.  Using  the 
tree  analogy,  local  pads  on  the  menu  could  point  to  frames 
or  nodes  in  a  totally  different  tree  vice  that  of  the 
frame's  children.  They  are  cross  reference  links.  The  final 
information  item  on  a  display  frame  consist  of  the  global 
pad  set.  These  pads  perform  often  repeated  actions  e.g.  go 
into  edit,  go  to  the  previous  frame,  find  information,  help, 
etc . 

Thousands  of  these  frames  can  be  connected  together 
to  form  what  is  called  a  "subnet".  Subnets  are  functional 
groupings  of  menus  that  form  some  report,  program,  or  other 
entity  when  interconnected. 
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2 .  ZOG  and  User  Integration 

When  interacting  with  ZOG,  the  user  is  in  one  of 
three  modes.  He  is  either  navigating,  invoking  a  program, 
or  editing  [Ref.  10].  Navigation  is  the  act  of  making  a 
selection  of  an  option,  local  pad,  or  global  pad  by  way  of 
the  mouse  pointing  device  or  keyboard.  The  system  reacts  by 
replacing  the  current  display  frame  with  that  of  the  new 
selection. 

Embedded  within  ZOG  are  agents  (application  and 
utility  programs)  written  in  the  Pascal  language.  These 
agents  are  used  in  planning  and  document  writing,  or  as 
interface  drivers  for  input/output  devices.  Because  ZOG 
supports  a  programming  environment  these  programs  can  be 
written  and  implemented  into  the  database  by  the  user 
himself . 

If  the  user  desires  to  invoke  an  agent  embedded 
within  ZOG,  he  usually  navigates  to  a  particular  display 
frame  on  which  the  program  is  listed  as  an  action  item, 
fills  in  the  required  parameters,  and  then  selects  the 
action.  McCracken  and  Akscyn  describe  an  action  item  as: 

"A  sequence  of  commands  in  the  ZOG  action  language  a 
simple  programming  language.  This  language  contains 
commands  for  traversing  the  network,  invoking  intrinsic 
utilities,  and  entering  the  editor,  [Ref.  11] 

The  third  area  of  interaction  between  ZOG  and  the 
user  is  editing.  Onboard  the  U.S.S.  CARL  VINSON,  a  user  has 
the  choice  of  two  different  editors.  The  principle  editor  is 
ZED  (ZOG  edit).  ZED  is  a  frrme  editor  that  is  used  for 
making  changes  to  the  database.  Its  main  purpose  is  to 
provide  an  instrument  for  creating  new  frames,  changing 
links  between  frames,  or  editing  the  contents  of  existing 
frames.  ZED  can  be  invoiced  from  any  frame  via  the  "edit" 
global  pad.  A  second  editor  called  SLED  (slot  edit)  is  also 


►  •  ■  -  ■  ■  ■  ■  ' 

available  within  ZOG.  This  editor  has  proved  much  easier  to 
use  than  ZED,  but  unlike  ZED,  it  cannot  be  used  to  create 
frames.  SLED  is  designed  for  use  in  applications  that 
require  fast,  accurate  input  cr  editing  of  information.  It 
is  especially  useful  in  running  ZOG  agents.  SLED  has  a  built 
in  error-checking  capability  that  matches  input  dates, 
times,  frame,  subnets,  and  other  pertinent  information 
against  its  data  base  to  ensure  their  validity.  With  its 
pop-up  type  menu  and  default  value  display,  SLED  allows  the 
user  to  quickly  input  required  parameters  for  an  agent  by 
invoking  electronic  toggle  switches  with  the  mouse  or 
;  keyboard.  One  application  that  relies  heavily  on  SLED  is  the, 

"expert"  system  called  AIRPLAN.  AIRPLAN  is  used  by  the  air 
operations  officer  in  monitoring  and  controlling  aircraft. 
When  aircraft  data  is  loaded  into  the  system  it  is  checked 
against  the  LOG  database  to  ensure  that  relevant  information 
!  concerning  the  pilot,  aircraft,  and  mission  correlates  with 

what  is  in  the  database.  These  parameters,  as  well  as  the 

j  _  parameters  required  by  all  agents,  are  entered  by  using 

i  SLED.  AIRPLAN  will  be  discussed  at  a  later  point  in  this 

j'  paper. 

D.  ZOG  AND  THE  U.S.S.  CARL  VINSON 

In  evaluating  a  system  such  as  ZOG,  several  criterion 
must  first  be  established  with  which  the  system  can  be 
measured  and  compared.  Still,  regardless  of  how  careful 
!  these  criterion  are  chosen,  a  system  can  seldom  be  deemed 

either  a  total  failure  or  a  total  success.  More  often  than 
not  it  lies  in  the  proverbial  gray  area  in  which  it  is  a 
success  in  one  arena,  a  failure  in  a  second,  and 

indeterm, nate  in  a  third. 


[ 


1.  Criterion  for  Success 


Criterion  used  in  evaluating  ZOG  will  vary  with  the 
perspective  from  which  it  is  being  viewed,  the 
interpretation  of  common  measures,  and  the  individual's 
knowledge  of  the  environment  in  which  the  system  is 
utilized. 

A  battle  group  commander,  for  example,  may  consider 
the  system  a  failure  because  it  cannot  use  standard  software 
already  developed  and  distributed  throughout  the  fleet.  An 
individual  commanding  officer  may  view  this  same  system  as  a 
success,  because  it  gives  him  the  information  he  requires  at 
the  time  he  needs  it.  The  user/technician  may  view  the 
system  as  unsuccessful ,  because  it  is  difficult  to  operate 
and  maintain.  Each  observation  is  valid,  yet  leads  to 
different  conclusions. 

One  common  criterion  heavily  used  in  evaluating  ZOG 
was  usage.  Newell  stated  that  "ZOG  is  a  success  to  the 
extent  that  it  becomes  used  for  actual  operations,  and  to 
the  extent  that  such  use  continues  and  expands"  [Ref.  12]. 
This  supposition  was  affirmed  by  Van  Matre,  Moy,  and  McCann 
as,  "the  best  measure  of  system  success  is  the  use  or 
non-use  of  the  system"  [Ref.  13].  While  this  premise 
appears  reasonable,  its  use  should  be  tempered  with  a 
thorough  knowledge  of  the  environment  in  which  the  system  is 
utilized,  otherwise,  erroneous  results  may  occur. 

Low  usage  of  the  Perq/ZOG  system  may  not  be 
significant  on  board  the  U.S.S.  CARL  VINSON  because  the  ship 
has  other  non- tactical  computer  systems  that  can  duplicate 
many  of  its  applications,  e.g.  WANG-Net,  Snap,  etc.  Also 
there  are  other  less  apparent  factors  that  could  account 
for  this  low  usage.  An  example  of  thes  is  evident  in  the 
SORM.  (Ship's  Organization  And  Regulations  Manual). 
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The  SORM  is  a  ship's  document  that  gives  detailed 
instructions  on  the  daily  routine  to  be  followed  by  a  ship. 
It  is  developed  and  tailored  by  ship's  personnel 
specifically  for  their  ship.  The  SORM  is  a  dynamic  document 
that  reflects  the  philosophy  of  the  commanding  officer,  but 
follows  the  format  and  guidelines  of  the  Navy's  SORM, 
OPNAVINST  3120.32  (Operational  Navy  Instruction  3120.32). 
OPNAVINST  3120.32  can  function  as  the  ship's  SORM  with  a  few 
page  insertions  and  some  pen  and  ink  changes,  as  is  often 
done  on  smaller  vessels.  Consequently,  development  of  a 
shipboard  version  is  usually  of  low  priority  compared  to 
more  pressing  documentation.  Therefore,  low  usage  on  a  SORM 
subnet  could  lead  to  an  erroneous  interpretation  and 
conclusion  about  ZOG's  suitability  for  developing  this 
particular  type  of  documentation.  In  reality,  the  usage  or 
non-usage  of  this  subnet,  might  be  mere  a  function  of  command 
emphasis  and  priorities  on  SORM  development,  than  a 
reflection  on  ZOG. 

2 ■  Evaluation  of  the  VINSON/ZQG  Project 

Three  areas  were  initially  selected  for  ZOG's 
implementation  on  board  U.S.S.  CARL  VINSON.  These  included 
the  SORM,  administrative  planning  and  evaluation 
(management),  and  weapons  elevator  maintenance  training. 
Later,  an  expert  system  called  AIRPLAN  was  added  along  with 
several  ad  hoc  applications.  Each  of  these  application  areas 
would  suffer  common  problems  endemic  to  either  ZOG  or  the 
Perqs.  These  problems  include  the  following: 

a.  "Difficulty  in  using  the  ZED  editor"  [Ref.  14).  The 
editor  has  proven  awkward  and  hard  to  use.  Once 
mastered,  it  requires  constant  use  to  maintain 
proficiency. 

b.  "ZOG  is  biased  too  much  toward  a  breadth-first  view" 
(Ref.  15].  This  is  unnatural  in  relation  to  the 
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normal  way  one  is  taught  to  think  and  read.  An 
analogy  of  this  problem  can  be  illustrated  in  reading 
a  book.  When  reading  a  book,  one  is  taught  to  read 
the  first  sentence  on  the  first  page,  the  second 
sentence  on  the  first  page,  etc.,  until  the  first 
page  has  been  read.  The  reader  will  then  progress 
through  the  second  page,  third  page  and  so  fourth 
reading  in  this  top  to  bottom  manner.  This  is  reading 
depth  first.  If  one  were  to  instead  read  the  first 
sentence  on  page  one  of  chapter  one,  the  first 
sentence  on  page  one  of  chapter  two  etc.,  until  he 
progressed  through  the  complete  book,  then  return  to 
the  beginning  and  do  the  same  for  the  second 
sentence,  this  would  be  breadth  first.  This  type  of 
thought  process  is  what  is  asked  of  the  user  in 
reading  ZOG  subnets. 

c.  Hardware/Software  problems.  During  the  U.S.S.  CARL 
VINSON's  1983  cruise,  problems  were  continually 
experienced  with  the  Ferq  minicomputers.  Thase 
problems  were  partly  due  to  the  equipment  being 
ill-designed  for  a  shipboard  environment,  and  partly 
due  to  equipment  being  installed  without  the  benefit 
of  shock  absorbers  to  compensate  for  pitch  and  roll 
of  the  ship,  or  basic  voltage  protection  to  ensure 
clean  power,  e.g.  isolation  transformers,  line 
regulators,  line  conditioners,  uninterruptible  power 
supply,  etc.  Consequently  the  Perqs  and  Ethernet 
experienced  continual  problems  with  electronic  boards 
and  other  electrical  components. 

ZOG  itself  was  a  major  source  of  frustration  to 
members  of  the  management  department.  Its  personnel  were 
expending  an  inordinate  amount  of  time  in  debugging  the 
system,  indicating  poor  quality  control  of  ZOG  software 
received  from  Mellon  Institute.  This  lack  of  quality  control 
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was  probably  a  direct  result  of  transferring  203  technology 
from  the  research  environment  to  an  operational  environment 
too  early  in  its  development  cycle.  To  exacerbate  the 
problem  even  further,  management  personnel  on  board  the 
U.S.S.  CARL  VINSON  were  attempting  to  integrate  code  being 
written  at  both  the  Mellon  Institute  development  site  and 
shipboard  operational  site.  This  difficult  task  was 
attempted  unaer  an  inflexible  set.  of  time  constraints  with 
poor  communication  between  the  two  sites.  When  the  ship  was 
at  sea,  it  could  take  up  to  a  month  for  a  mail  query  to  be 
answered . 

a.  The  SORM 

Nicholas  Van  Matre,  Melvyn  Moy  and  Patrick 
McCann  concluded  in  their  evaluation  of  ZOG  that  ,!The  SORM 
was  not  suitable  as  an  organizing  element  for  all  functional 
applications  as  was  originally  conceived"  [Ref.  16).  They 
further  found  that  there  was  a  disproportionate  usage  of 
SORM  subnets,  i.s.  some  portions  were  meticulously  developed 
and  were  providing  extremely  useful  management  support, 
while  other  portions  of  the  SORM  subnet  remained  nothing  but 
shell . 

The  rational  for  this  phenomenon  was  two-fold: 

1.  "Time  was  a  limiting  factor"  [Ref.  17).  By  this, 
they  mean  that  Perq/ZOC-  development  was  performed  by 
shipboard  users  collaterally  with  their  primary 
responsibilities.  These  users  had  to  develop  SORM 
subnets  in  their  own  time  after  fulfilling  tneir 
foremost  shipboard  duties.  This  is  closely  related  to 
command  emphasis,  which  was  previously  discussed. 

2.  The  users  had  difficulty  in  "instantiating  their  job 
as  a  subnet"  [Ref.  18).  The  user  who  was  an  expert 
on  the  business  side  of  the  SORM,  also  had  to  perform 
the  technical  function  of  fitting  and  copying  his 
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job  into  the  ZOG  database.  This  is  a  skill  that 
requires  some  expertise  in  choosing  meaningful  levels 
of  division  and  a  good  working  knowledge  of  ZED 
[Ref.  19].  Without  this  skill,  and  with  limited  or 
non-recent  training  in  this  area,  many  users  became 
extremely  frustrated. 

Besides  the  above,  hardware  and  software 
problems  had  a  discernible  effect  on  SORM  development.  The 
management  department  on  board  the  U.S.S.  CARL  VINSON  had 
completed  installing  the  ZOG  shell  for  SORM  subnets  before 
the  ship's  initial  cruise  in  1983.  Because  of  the  size  of 
these  SORM  subnets  (over  10,000  frames),  the  SORM  database 
was  distributed  over  four  host  Perq  minicomputers.  Four 
other  Perqs  held  read  oniy  secondary  copies.  The  other 
twenty  Perqs  had  the  capability  of  accessing  this  SORM 
database  through  the  Ethernet  local  area  network.  During  the 
cruise,  ship  personnel  experienced  problems  with  both  the 
Ethernet  and  the  Perqs,  which  precluded  reliable  access  to 
the  SORM  database  by  all  except  the  four  host  computers. 
This  in  effect  limited  the  number  of  locations  and, 
therefore,  the  number  of  people  that  could  access  the  SORM 
database  at  one  time.  To  further  frustrate  the  user,  several 
other  Perq  minicomputers  ceased  to  function  as  the  cruise 
progressed.  Fewer  and  fewer  computers  were  available  on 
which  to  run  ZOG,  thus  further  impacting  SORM  development. 
By  the  end  of  the  cruise  there  were  only  nineteen 
functioning  Perqs. 

The  combination  of  these  problems  has  served  to 
frustrate  the  user  and  inhibit  online  development  of  the 
SORM .  ■ 


b.  Weapons  Elevator  Maintenance  Training 

A  complex  application  attempted  with  ZOG  was  an 
on-line  technical  manual  for  the  ship's  weapons  elevators. 
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This  manual  was  to  provide  maintenance  personnel  of  the 
ship's  weapons  department  with  technical  support  in 
repairing,  maintaining,  and  operating  the  ship's  weapons 
elevators.  Additionally,  it  was  to  serve  as  a  training 
device  for  all  members  of  the  G-3  division.  The  manual 
itself  was  hosted  on  three  Perq  minicomputers  that  were 
connected  to  a  laser  video-disk  player  and  CRT  display 
monitor . 

During  ship  construction  in  Newport  News, 
Virginia,  members  of  the  weapons  department  G-3  division 
made  detailed,  multiple-  view  video  tapes  of  each  step  in 
assembly  and  installation  of  the  weapons  elevators.  On 
completion,  more  color  video  tapes  were  made  showing  the 
elevators  in  operation  with  appropriate  motion  and  sound. 
These  video  tapes  were  then  moved  to  laser  video  disks. 
Consequently,  a  complete  pictorial  history  was  made  of  each 
weapons  elevator  aboard  U.S.S.  CARL  VINSON. 

Once  developed,  the  user  of  this  system  would 
read  the  on-line  narrative  portion  of  the  technical  manual, 
and  then  look  at  the  picture  display.  Like  the  SORM,  all 
material  was  categorized  into  three  functional  ZOG  trees. 

1.  UNDERSTAND:  This  section  breaks  the  elevator  into 
components,  and  describes  their  location  and 
function.  While  this  section  was  easy  to  comprehend, 
it  was  very  difficult  to  actually  construct  a  tree. 

2.  OPERATE:  This  is  a  combination  description  and 

demonstration  of  elevator  operation. 

3.  EVALUATE/MAINTAIN:  This  provides  the  technicians  with 
preventive  maintenance  procedures,  specification  and 
electrical  schematics. 

While  the  on-line  elevator  maintenance  manual 
proved  an  excellent  use  of  the  new  SCG  technology,  it  was 
plagued  v/ith  both  software  and  hardware  problems.  The  Perq 
computers  suffered  electronic  circuit  board  problems  due  to 


23 


power  fluctuations,  while  the  laser  video  disk  player 
experienced  alignment  problems  due  to  the  motion  and 
vibration  inherent  on  board  ship.  In  the  software  arena,  a 
great  deal  of  effort  was  expanded  in  continually  debugging 
due  to  problems  between  the  operating  system  and  ZOG.  One 
other  area  in  which  the  weapons  elevator  program  proved 
deficient  was  video  disk  expansion  capability.  It  proved  too 
expensive  to  add  to  the  current  disk  or  make  more  disks. 
Hence,  before  completion  of  the  on-line  technical  manual, 
the  video  disk  literally  ran  out  of  space,  resulting  in 
later  additions  to  the  technical  manual  being  narrative  only 
[Ref.  20]. 

c.  AIRPLAN 

AIRPLAN  is  an  "expert"  system  -chat,  was  developed 
as  an  aid  and  tool  for  the  air  operations  officer  in 
monitoring  and  controlling  carrier  aircraft.  It  is  not  a 
part  of  ZOG,  but  uses  ZOG  as  an  interface  system  between 
itself  and  the  user. 

The  AIRPLAN  program  is  a  rule-based,  decision 
support  system  that  maintains  a  summary  status  on  all 
aircraft  operationally  controlled  by  the  U.S.S.  CARL  VINSON, 
and  recommends  actions  to  be  taken  as  different  situations 
arise,  e.g.  emergency  procedures.  It  is  also  capable  of 
modeling  aircraft  scenarios  without  requiring  actual 
aircraft  launch. 

Before  flight  operations,  daily  flight  schedules 
and  initial  status  of  all  aircraft  are  loaded  into  the 
AIRPLAN  net.  This  includes  3uch  information  as  mission, 
pilot  name,  primary  and  secondary  buttons  (communication 
frequencies  ),  and  initial  fuel  and  ordinance  loads  for  each, 
aircraft.  These  inputs  are  loaded  using  SLED  and  are 
automatically  checked  for  errors.  Output  includes  a  hardcopy 
flight  schedule,  ordnance  loading  plan  and  an  emergency 
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landing  plan.'  Once  airborne,  each  aircraft  is  monitored  and 
its  real  time  status  is  summarily  displayed  on  a  Perq 
minicomputer.  Included  in  this  display  is  the  amount  of 
remaining  fuel  in  pounds  and  time  remaining  before  certain 
critical  decisions  must  be  made,  i.e.  land,  refuel  from  an 


air  tanker 

,  etc . 

The  AIRPLAN  net  is  also 

compri sed 

of 

emergency 

subnets 

for  each  aircraft  which 

di splay 

a 

procedural 

check- 

off  list  for  different 

types 

of 

emergencies 

On  a 

success/failure  continuum. 

AIRPLAN 

has 

proven  to  lie  toward  success  for  two  reasons. 

1.  It  is  an  alternative  to  the  slower,  manpower 
intensive,  manual  systems  that  are  used  on  all  other 
aircraft  carriers. 

2.  AIRPLAN  displays  can  be  channeled  to  the  ship's 
secure  closed  circuit  television  system,  as  well  as 
the  Perqs.  This  allows  monitoring  of  air  operations 
from  many  compartments  aboard  ship  including  all 


squadron  ready  rooms, 

deck  control. 

the 

bridge. 

lower 

and  hanger 

Although  AIRPLAN 

is 

popular 

among 

personnel 

concerned  with  flight  operations  it  cannot  be  relied  on  in 
an  emergency,  because  it  suffers  from  the  same  hardware  and 
software  reliability  problems  that  afflict  the  SORM  and 
Weapons  elevator  programs. 


d.  Planning  and  Evaluation  Subnets 


Planning  and  Evaluation  (P  and  E)  subnets 
complete  the  triad  of  original  ZOG  applications  first 
envisioned  for  implementation  on  board  U.S.S.  CARL  VINSON. 
These  subnets  were  intended  to  support  both  SPECIFIC  PLANS 
(one-time  activities),  and  GENERIC  PLANS  (iterative 
activities)  at  the  department  head  level  and  above.  Newell, 
McCracken,  Robertson  and  Akscyn  described  this  on-line 
planning  as  follows: 
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Plans  will  exist  in  an  integrated  ZOGnet,  which  will  be 
updated  and  modified  continually  as  each  plan  is 
extended  and  changed.  Exploration  of  plans  from 
different  perspectives  will  be  possible,  e.g.  by  task, 
by  persons  or  by  resources.  Some  automatic  monitoring  of 
plans  for  consistency  and  critical  events,  and  some 
joro^agat  jon  of  status  through  plans  will  be  possible. 


Within  each  of  these  subnets,  two  basic  types  of 
ZOG  developed  plans  can  be  displayed.  These  are  Specific 
Responsibility  Task  Nets  and  Specific  Responsibility  Time 
Line  Nets.  The  Task  Nets  show  the  hierarchical  relationship 
of  the  tasks  to  be  performed,  i.e.  it  breaks  them  down  into 
components  and  subcomponents,  but  not  in  the  chronological 
order  for  completion.  It  also  indicates  the  person  or  group 
responsible  for  accomplishing  the  task,  the  required  date  of 
completion,  and  the  expected  amount  of  time  to  complete  the 
tlcsSlv .  TiiS  Time  Li J. Metis  €Xil2.  jDx  tl  time  I'clci'tiOn&liipS  tet  r6«n 
the  tasks.  These  tasks  could  be  sorted  by  starting  a  te, 
completion  date,  and  over  time  periods  varying  between  one 
day  and  eighteen  months.  By  making  a  selection  from  the  Time 
Line  Net,  the  related  task  frame  of  the  Task  Net  along  with 
its  detailed  information  will  also  be  displayed.  A  hardcopy 
of  these  timeline  charts  could  be  printed  if  desired.  The 
format  of  these  plans  is  generally  that  of  a  standard  Gantt 
chart. 


With  the  installation  of  ZOG  on  board  U.S.5. 
CARL  VINSON,  many  formally  structured  P  and  E  subnets  were 
established  for  ship's  departments  and  personnel.  See  table 
I  for  assigned  machines  and  locations. 

Although  these  planning  and  evaluation  subnets 
suffered  from  the  same  hardware  and  software  problems  as  did 
the  SORM,  they  appear  to  have  been  used  much  more 
extensively.  During  the  U.S.S.  CARL  VINSON's  1983  cruise, 
108  subnets  were  created  besides  the  formal  ones  enumerated 
above.  Of  these  subnets,  95  can  be  classified  as  primarily 
supporting  planning.  (Ref.  22} 
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TABLE 

I 

Assigned  Subnets  and 

Machine 

Locations 

ASSIGNED  TASK  SUBNETS 

MACHINE  LOCATION 

Air  Officer 

( AOPS 

TASK) 

Air  Ops  office 

Aviation  intermediate 

Maintenance  Department 

( IMDO 

TASK) 

AIMD  Office 

Management  Department 

(MGl’O 

TASK) 

Conference  room 

Engineering  Department 

( ENGO 

TASK) 

Engineers  logroom 

Medical  Department 

(HMED 

TASK) 

Medical  office 

Navigation  Department 

(NAVO 

TASK) 

Ship's  bridge 

Operations  department 

(OPSO 

TASK) 

Ops  office 

Personnel  Department 

(PERS 

TASK) 

PERS  office 

Reactor  Department 

( REAC 

TASK) 

REAC  office 

Strike  OrS  Department 

(OXOE 

TASK) 

Strike  OPs  Office 

Supply  Department 

( SUPO 

TASK) 

Supply  office 

Senior  Chaplain 

Chaplain's  office 

Weapons  Department 

(WEPS 

TASK) 

Weapons  office 

Executive  Officer 

( YYXO 

TASK) 

XO ' s  office 

Van  Matre,  Moy,  and  McCann  attribute  this 
proliferation  of  activity  in  creating  subnets  midway  through 
the  cruise  to  two  factors. 

1.  The  users  had  gained  two  months  additional  experience 
with  ZOG,  and  were  therefore  becoming  more 
proficient . 

2.  ZOG  became  easier  to  use  because  an  update  to  the 

software  "enabled  a  user  to  be  presented  with  his  own 
unique  'top  frame  '  when  first  logging  on, 

instead  of  the  ZOG  data  base  top  frame" 

(Ref.  23]. 


27 


While  these  two  factors  undoubtedly  contributed  to  expansion 
of  P  and  E  subnets,  the  cruise  itself  was  probably  the 
primary  reason  for  this  noted  increase.  Personnel  who 
actually  developed  and  used  these  subnets  were  on  board  the 
ship  24  hours  a  day  with  no  interruption  from  land- line 
telephones  or  ship  visitors.  This  translares  into  increased 
manhour  availability  for  creating  these  subnets.  The  cycle 
of  the  cruise  is  also  partly  responsible  for  the  development 
of  these  planning  nets.  When  a  ship  first  gets  underway  for 
a  major  cruise,  its  operational  tempo  is  one  of  training  and 
operational  commitments.  Its  near  term  planning  consist 
primarily  of  fulfilling  these  commitments.  About  halfway 
through  a  cruise,  the  ship  will  shift  its  planning  emphasis 
from  an  almost  pure  operational  mode,  to  one  that  will 
prepare  it  for  the  myriad  of  inspections,  training 
requirements,  maintenance,  and  other  demands  than  will 
inundate  it  on  its  return  to  the  United  States.  It  is  a 
combination  of  all  these  factors  taken  together  that 
impacted  on  the  proliferation  of  P  and  E  subnets  during 
U.S.S.  CARL  VINSON's  first  world  cruise. 

One  specific  task  that  consistently  used  oi.e  of 
these  planning  subnets  was  the  development  of  U.S.S.  CARL 
VINSON  Greensheets.  These  are  "plans  of  the  day"  (daily 
plans)  that  are  universally  used  on  all  U.S.  Navy  ships. 
They  list  deviations  from  the  daily  routine  of  shipboard 
life,  i.e.  changes  in  meal  hours,  meetings  and  scheduled 
events  along  with  times  and  personnel  concerned.  Onboard 
U.S.S.  CARL  VINSON,  the  department  heads  would  give  the 
Assistant  Operations  Strike  Officer  the  information  to  be 
included  in  the  daily  Greensheets.  It  took  him  about  two 
hours  to  prepare  them  after  receiving  the  last  input.  This 
is  about  the  same  time  it  takes  to  prepare  the  plan  of  the 
day  on  other  Navy  ships.  The  main  difference  between  these 
Greensheets  and  another  ship’s  plan  of  the  day  is  that  the 
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Greensheets  actually  included  a  two  day  plan  to  allow  for 
better  planning,  and  could  be  electronically  disseminated 
almost  immediately  to  the  Perqs.  Hardcopy  Greensheets  still 
had  to  be  run  off  and  delivered  newspaper  style  to  the  vast 
majority  of  the  crew. 

Another  area  where  planning  subnets  were  used 
frequently  was  in  getting  the  ship  underway.  To  get  a  ship 
underway  requires  a  great  deal  of  planning  and  coordination. 
Tugs  must  be  scheduled,  charts  corrected,  engineering 
equipment  tested  and  brought  on-line,  food  and  supplies 
brought  on  board,  etc.  Preparations  will  usually  start  days 
and  sometime  weeks  before  actually  taking  in  the  lines  and 
getting  the  ship  underway.  A  ZOG  planning  and  evaluation 
subnet  was  used  on  the  U.S.S.  CARL  VINSON  to  provide  an 
online  and  hardcopy  checkoff  list  to  ensure  that  all 
required  tasks  were  completed  at  the  proper  time  and  in  the 
order  they  were  scheduled.  By  keeping  this  information 
on-line,  an  up-to-date  date  tailored  plan  could  be 
automatically  created,  and  task  relevant  information 
displayed  for  either  a  specific  person  or  billet  (specific 
assigned  shipboard  job) .  The  status  of  overall  underway 
preparations  was  also  available  for  concerned  personnel. 

A  third  area  where  this  type  of  subnet  proved 
useful  was  in  preparing  for  the  ORSE  (Operational  Readiness 
System  Evaluation).  This  is  an  involved  inspection  of  the 
engineering  department  on  board  a  nuclear  vessel.  Both  the 
engineer  and  reactor  officers  used  planning  and  management 
nets  to  assimilate  and  correlate  information  concerning 
personnel  availability,  training,  checkoff  list,  schedules, 
etc . 

It  appears  that  planning  and  evaluation  subnets 
were  used  extensively  on  board  the  U.S.S.  CARL  VINSON 
despite  hardware  and  software  problems.  One  possible  reason 
for  this  is  that  the  only  alternative  solution  was  often 
manual  mode. 
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E.  A  CRITIQUE  OF  TECHNOLOGY  TRANSFER 


If  the  sole  objective  of  the  20G  technology  transfer 
concept  was  to  expedite  the  transition  of  technology  from 
the  research  laboratory  of  Carnegie-Mellon  to  the 
operational  environment  of  the  U.S.S.  CARL  VINSON,  then  it 
is  an  unqualified  success.  Success,  however,  is  a  nebulous 
term  that  varies  with  time  and  the  perspective  from  which 
the  system  is  being  judged.  For  the  U.S.S.  CARL  VINSON,  it 
hinges  more  on  the  future  prospects  of  20G  and  its  progeny 
than  its  past.  This  is  as  it  should  be,  because  the  Perq/ZOG 
system  as  implemented  on  board  the  U.S.S.  CARL  VINSON  has 
been  fraught  with  problems.  The  reason  for  this  is 
four-fold. 

1.  ZOG  was  originally  designed  to  run  on  the  SPICE 

operating  system.  Two  months  prior  to  the  ship's  1983 
cruise  this  operating  system  was  deemed 

inappropriate  and  its  planned  implementation  on  board 
the  U.S.S.  CARL  VINSON  canceled.  The  standard  Perq 
operating  system  was  designated  to  take  its  place. 

2.  ZOG,  when  first  implemented  in  an  operational 
environment  was  a  first  generation  system 
undergoing  constant  development  at  a  rapid  pace.  In 
July  of  1983,  version  19.1  was  being  used  on  board 
U.S.S.  CARL  VINSON.  By  October  of  1983,  the  ship  had 
installed  version  23.1.  Each  version  represented  a 
major  improvement  over  its  predecessor,  representing 
everything  from  implementation  of  an  electronic  mail 
system  to  installation  of  the  new  personalized  ZOG 
frame  previously  mentioned. 

3.  ZOG  had  been  installed  too  fast.  A3  a  direct  result 
of  the  rapidity  of  ZOG's  implementation,  many 
problems  occurred  that  could  have  been  minimized  or 
prevented.  One  example  of  this  is  in  the  area  of 
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hardware.  Both  the  Perq  minicomputers  and  Ethernet 
system  experienced  a  great  deal  of  problems  with 
electronic  components  as  a  result  of  voltage 
fluctuations.  These  problems  were  a  direct  result  of 
utilizing  ship's  power  without  the  benefit  of  voltage 
protection  devices.  When  surge  suppressors  (voltage 
line  filters)  were  finally  installed  three  months 
into  the  cruise,  electronic  fault  problems  decreased 
[Ref.  24].  While  voltage  spikes  can  increase  fail 
time  on  electronic  equipment,  a  major  power  surge 
will  really  wreak  havoc  on  computer  electronics.  In 
starting  a  large  induction  motor  for  example,  a 
tremendous  amount  of  current  draw  will  be 
experienced;  a  300  AMP  electric  motor  will  initially 
draw  approximately  1500  amps  of  current.  On  some 
ships,  depending  on  the  power  source,  this  can  result 
in  severe  damage  to  any  computer  or  other  electronic 
equipment  that  is  not  protected  with  something  more 
than  a  simple  surge  protector. 

4.  A  fourth  reason  the  Perq/ZOG  system  appeared  to  have 
so  many  problems  is  simply  because  the  users  gave  the 
system  a  good  workout.  If  the  system  had  not  been 
relentlessly  used,  then  many  of  these  problems  could 
have  gone  unnoticed. 

1 .  Disadvantages  of  ZOG 

ZOG  exhibits  many  disadvantages  as  it  is  presently 
installed  on  board  U.S.S.  CARL  VINSON.  These  include  the 
following: 

a.  "ZOG  sacrifices  efficiency  of  particular  applications 
to  get  integration"  [Ref.  25].  ZOG  makes  many 
compromises  because  it  is  attempting  to  be  all  things 
to  all  types  of  users.  This  results  in  high 
processing  time  and  memory  overhead  within  the 
computer  itself. 
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b.  "ZOG  doesn't  support  a  fast  database  query  language" 
[Ref.  26].  To  achieve  flexibility  and  portability  of 
the  database  ZOG  data  is  stored  in  mass  storage  as 
text  files.  This  requires  a  great  deal  of  computer 
overhead  when  parsing  and  unparsing  ZOG  frames. 

c.  ZOG  is  "Biased  too  much  toward  a  breadth- first  view" 
[Ref.  27].  This  was  discussed  in  an  earlier  part  of 
this  chapter. 

d.  "ZOG  cannot  be  used  over  standard  telecommunication 
lines."  fRef.  28]  A  1200  baud  transmission  rate  is 
too  slow  for  using  ZOG.  It  should  be  more  than  9600 
baud  to  obtain  the  full  benefit  of  this  type  of 
database . 

e.  ZOG  experiences  decreasing  speed  as  the  database 
grows.  The  U.S.S.  CARL  VINSON  experienced  a  response 
time  of  .5  seconds  when  accessing  data  that  was 
resident  on  the  machine  being  used.  If  the  data  had 
to  be  brought  in  from  a  part  of  the  database  resident 
on  another  machine,  then  access  time  was  increased  to 
1.5  seconds  when  both  machines  were  running  normally. 
[Ref.  29]  The  original  design  goal  for  ZOG  was  near 
.25  seconds,  and  was  regularly  reached  in  the 
laboratory.  As  database  use  and  size  increase,  speed 
can  expect  to  decrease  even  more. 

2 ■  Advantages  of  ZOG 

Strictly  from  a  user's  viewpoint,  a  ZOG  type  system 
has  several  advantages  over  a  more  conventional  mainframe 
architecture,  or  even  a  network  of  mini/microcomputers  that 
use  non-database  type  software.  Some  of  these  advantages  are 
as  follows: 

a.  Redundancy  of  hardware.  Those  who  have  experienced 
shipboard  life  quickly  realize  that  equipment  wears 
faster,  breaks  quicker,  and  has  a  shorter  life  span 
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than  equi valent  equipment  that  is  used  in  a  less 
hostile  environment.  This  is  especially  true  of 
computer  equipment.  It  must  be  designed  to  contend 
with  high  humidity,  temperature  variances,  salt  air 
corrosion,  power  fluctuations,  and  structural 
movement  of  the  ship  itself.  Even  then,  all  other 
things  being  equal,  shipboard  installed  equipment 
will  still  have  a  shorter  life  expectancy  and  greater 
failure  rate  than  equivalent  equipment  ashore.  A 
redundant  hardware  architecture,  such  as  the  Perq 
system,  means  that  the  entire  system  will  not  come  to 
a  crashing  halt  as  a  result  of  the  loss  of  one,  two 
or  even  more  computers. 

b.  Redundancy  of  data.  This  principle  carries  over  into 
the  software  area  as  well.  By  using  a  distributed 
database  the  loss  of  one  or  more  nodes  does  not  bring 
the  whole  system  to  a  screeching  halt. 

c  Ease  of  use.  This  is  especially  important  in  a 
shipboard  environment  where  high  rates  of  personnel 
turnover  often  occur.  A  computer  novice  can  be  taught 
t  ■  navigate  through  ZOG  in  less  than  thirty  minutes. 
In  two  hours  he  can  be  taught  to  add  new  material  to 
tue  database  with  ZED.  (Ref.  30] 

d.  Browsing  capability.  Closely  tied  to  ease  of  use  is 
browsing  capability.  Instead  of  having  to  search  the 
database  using  query  methods,  the  new  user  can  jump 
right  in  and  start  exploring  the  database  through 
random  browsing.  This  capability  in  effect  functions 
as  a  tutor  allowing  the  new  user  to  explore  the 
database  and  familiarize  himself  with  how  it  is  set 
up.  The  ZOG  system  defaults  to  the  browsing  mode  when 
it  is  entered. 

e.  Large  database.  A  fifth  advantage  of  ZOG  is  that  it 
supports  a  large  database, e . g .  the  U.S.S.  CARL  VINSON 
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had  over  30,000  frames.  Theoretically,  the  only  limit 
on  size  is  mass  memory  of  the  hardware  device,  and 
possibly  some  operating  system  constraints. 

f.  Allows  more  information  to  be  produced  from  a  given 
amount  of  data.  In  effect,  a  database  allows  a  piece 
of  data  to  be  entered  once  and  used  by  everyone, 
instead  of  everyone  entering  that  same  piece  of  data 
in  a  personalized  file.  Thus,  one  piece  of  data  is 
supplying  more  information  to  more  people.  This  is 
especially  important  on  board  ship.  For  example,  if  a 
supply  officer  were  to  keep  his  complete  requisition 
status  (status  of  items  on  order)  in  a  database,  the 
engineer,  operations  officer,  or  other  interested 
personnel  could  obtain  the  latest  information  simply 
by  addressing  the  database.  This  would  free  up  the 
supply  officer  and  his  men  for  more  constructive 
tasks,  as  well  as  keeping  appropriate  personnel 
apprised  of  their  requisition  status.  The  checkoff 
sheet  for  getting  the  ship  underway  is  a  working 
example  of  this  concept.  Assignment  of  task  and 
times  which  will  result  in  the  completion  of  required 
activities  needed  to  get  the  ship  underway  are  loaded 
into  the  ZOG  database.  This  information  is  then  used 
by  anyone  on  the  ship  with  access  to  a  Perq  who  has 
need  of  this  data. 

g.  Elimination  of  data  duplication.  By  using  a  database 
system,  many  artificial  partitions  used  to  separate 
data  in  a  conventional  file  system  are  eliminated. 
This  allows  a  specific  piece  of  data  to  be  entered 
once,  yet  used  over  and  over  by  many  different 
programs.  Consequently,  the  number  of  times  that  a 
specific  piece  of  data  is  entered  into  the  database 
is  reduced,  while  at  the  same  time  the  amount  of 
information  that  can  be  derived  from  that  particular 
piece  of  data  is  increased. 
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Additional  advantages  derived  from  ZOG's  distributed 
database  include  data  integrity,  data  independence  from 
embedded  programs  or  agents,  and  the  capability  for  better 
data  management. 

F.  CONCLUSIONS 

ZOG  appears  to  be  much  more  flexible  in  areas  which  can 
use  the  system  primarily  as  an  interface  for  embedded 
programs  or  other  technology  such  as  AIRPLAN  and  the  weapons 
elevator  technical  manual.  It  is  inflexible  in  areas  where 
it  must  function  as  an  organizing  element, i.e.  used  as  the 
primary  tool  for  creating  and  arranging  difficult  structural 
documentation,  such  as  the  SORM.  While  it  can  be  made  to 
support  planning  and  evaluation  subnets,  much  of  this 
support  is  really  done  with  the  brute  force  method.  Most  of 
the  planning  functions  could  be  done  more  efficiently  by  use 
of  a  standard  turnkey  system  with  an  electronic  mail 
capability.  Technology  transfer  does  offer  more  reliability 
than  the  other  systems  presently  on  U.S.S.  CARL  VINSON 
primarily  because  of  its  distribution  feat  ires.  It  is  loss 
prone  to  total  failure  due  to  fire,  water  or  other 
catastrophe  than  is  a  centralized  system. 

With  the  influx  of  new  personnel,  ZOG  usage  will 
probably  go  down.  This  is  because  many  of  the  new  people, 
while  just  as  dedicated  as  the  older  personnel,  will  not 
have  benefited  by  such  a  close  association  with  the 
developers  as  did  the  original  personnel.  They  will  also 
have  more  systems  to  chose  from. 

While  this  will  probably  mean  that  ZOG  is  used  on  a  less 
frequent  basis,  it  should  not  be  abandon.  Instead,  it  should 
be  utilized  in  those  areas  in  which  it  has  proved  the  most 
feasible . 


III.  WANG 

A.  INTRODUCTION 

Some  of  the  more  common  computing  equipment  found  on 
board  Naval  ships  and  installations  in  recent  years  has  been 
manufactured  by  WANG  Laboratories  Inc. (WANG).  This 
phenomenon  is  a  direct  result  of  WANG's  strategy  of 

vice  "data 
While  an 
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marketing  its  products  as  "word  processers" 
processers",  as  most  other  vendors  have  done, 
off-the-shelf  WANG  word-processing  machine  is 
primarily  to  perform  word  processing  functions, 
turnea  xulo  a  power fu x  data  processor  with  just  u  mw  * ^ ^ 
adjustments  and  the  installation  of  the  appropriate 
software.  Nevertheless,  up  until  1982,  WANG  word-processing 
products  had  been  listed  and  procured  under  the  GSA  (General 
Services  Administration)  contract  schedule  as  office 
equipment  (federal  supply  class  74)  instead  of  under  the 
more  restrictive  GSA  contract  schedule  for  automatic  data 
processing  equipment  (federal  supply  class  70).  In  1982  the 
Navy  issued  an  instruction  defining  automatic  data 

processors  and  equipment  by  purpose  instead  of  by  class 
[Ref.  31j.  With  the  issuance  of  this  instruction  Navy 
commands  could  no  longer  purchase  a  WANG  word  processor  and 
convert  it  into  a  data  processing  machine  without  having  to 
go  through  the  extensive  and  complicated  acquisition 
procedures  required  for  procuring  automated  data  processing 
equipment. 

While  the  majority  of  WANG  processers  on  board  naval 
vessels  are  used  strictly  for  word  processing,  there  are  six 
noted  exceptions.  Five  of  these  exceptions  are  the  WANG 
VS-80  prototype  SNAP  II  systems  installed  on  board  the 
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U.s.s.  David  R.  Ray,  U.S.S.  Kidd,  U.S.S.  Scott,  U.S.S. 
Chandler,  and  the  U.S.S.  Callaghan.  The  U.S.S.  Fife  and  the 
U.S.S.  New  Jersey  were  originally  outfitted  with  these  WANG 
VS-80  prototypes  as  well,  but  have  since  had  them  replaced 
with  the  Karris  SNAF  II  system.  The  WANG  systems  originally 
installed  on  the  U.S.S.  Fife  and  the  U.S.S.  David  R.  Ray 
were  implemented  as  SNAP  II  prototypes  by  the  Commander 
Naval  Ships  Engineering  System  Command  ( COMNAVSEASYSCOM) , 
whi’e  those  installed  on  the  remaining  five  ships  were 
procured,  implemented  and  designated  as  interim  SNAP  II 
systems  by  Commander  Naval  Surface  Forces  Pacific 
(COMNAVSURFPAC) .  This  was  done  before  the  selection  of  the 
Navy's  standard  SNAP  II  computer  system  to  get  non-tact.ical 
automation  capability  on  board  each  of  these  newly 
commissioned  ships.  Software  was  jointly  developed  and 
implemented  by  NAVSEA  (PMS-389)  and  Navy  Management  Systems 
Support  Office  (NAVMASSO)  Norfolk.  In  July  1983  NAVMASSO 
placed  a  moratorium  on  further  software  development  for  the 
WANG  VS-80  system.  This  was  followed  in  August  1983  by 
COMNAVSURFPAC  making  known  his  intentions  to  replace  the 
WANG  prototype  system  with  the  standard  Harris  SNAP  II  as 
they  become  available.  [Ref.  32] 

The  other  installation  which  uses  a  WANG  system  for  more 
than  simple  word  processing  is  on  board  the  U.S.S.  CARL 
VINSON.  It  is  this  system  that  will  be  the  focus  of  this 
chapter. 

B-  WANG  AND  THE  U.S.S.  CARL  VINSON 

In  June  1980,  a  WANG  System-20  computer  was  leased  and 
installed  in  a  naval  office  building  being  used  by  the 
precommissioning  crew  of  the  Navy's  aircraft  carrier,  U.S.S. 
Carl  Vinson,  then  under  construction  at  the  Newport  News 
Shipbuilding  and  Drydock  Company  in  Newport  News,  Virginia. 
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It  consisted  of  a  single  terminal,  a  floppy  disk  drive,  and 
one  printer.  The  system-20  ran  what  is  called  "Glossary 
Language "  besides  standard  COBAL. 

Glossary  language  is  a  key  word  oriented  language  that 
can  be  used  for  calling  a  library  of  routines,  utilities,  or 
series  of  keystrokes.  It  is  an  integral  part  of  the  word 
processing  package  available  on  the  System-20.  While  using 
this  language  is  analogous  to  programming  a  PF  key  on  an  IBM 
System,  it  will  do  much  more.  For  example,  the  glossary 
function  can  be  programmed  to  format  standard  documentation 
such  as  a  form-letter.  When  activated,  it  will  print 
required  .information  like  a  letter  head,  place  in  an 
automatic  return  and  jump  down  to  the  address  area.  The  user 
will  input  the  name  and  address  of  the  intended  recipient 
and  hit  the  return  key.  At  that  time  the  glossary  language 
will  print  out  the  remainder  of  the  letter. 

The  primary  purpose  for  obtaining  the  System- 20  was  to 
enumerate  and  track  the  thousands  of  tasks  requiring 
completion  before  the  ship  could  be  commissioned.  This 
planning  and  control  function  was  to  be  the  precursor  of  the 
planning  and  evaluation  subnets  that  would  later  be 
developed  and  used  on  the  Perq/ZOG  system. 

Once  installed,  the  System-20  proved  to  be  extremely 
useful.  A3  a  result.  Captain  Richard  Martin,  the 
prospective  commanding  officer  of  the  U.S.S.  CARL  VINSON, 
decided  to  expand  its  users  to  include  the  ship' s  department 
heads.  By  March,  it  had  become  apparent  that  the  system  was 
toe  small  to  perform  all  the  functions  and  tasks  now 
required  of  it.  Consequently,  in  April  1980  the  System-20 
was  traded  in  for  a  System-30  that  was  also  leased  from 
WANG.  The  System-30  was  configured  with  10  terminals,  3 
printers,  and  a  30-MB  (megabyte)  hard  disk  drive. 

Shortly  after  the  WANG  System-30  was  installed,  it 
became  apparent  that  computing  demands  for  both  the 
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precommissioning  planning  and  control  requirements  the 
department  heads  had  been  greatly  underestimated.  With  the 
inclusion  of  department  heads  in  the  coterie  of  WANG  users, 
the  proverbial  door  had  been  opened  for  personnel  within  the 
various  departments  themselves  to  access  the  system.  Once 
this  occurred,  contagion  for  the  WANG  System-30  began  to  run 
rampant  throughout  the  ship.  Personnel  from  the 
administrative,  medical,  engineering,  personnel  and  other 
departments  began  to  find  new  and  innovative  ways  to  use  the 
WANG  to  make  their  own  work  more  efficient  and  effective.  As 
a  direct  result,  a  WANG  VS-80  system  was  leased  in  July  1980 
to  upgrade  the  System-30.  The  System-30  was  retained  on 
board  the  ship  for  use  by  the  engineering  department  until 
September  1983,  when  its  lease  ran  out  and  it  was  returned 
to  WANG.  The  VS-80  leased  from  WANG  increased  the  size  of 


the  hard  disk  drive  from  30-mb  to  90-mb  of  storage.  To 
ensure  that  enough  memory  was  available,  an  additional  7 5 -mb 
was  procured  and  added  to  the  VS-  80  specifically  to  upgrade 
the  planning  and  control  functions. 

Although  the  VS-80  system  with  additional  memory  was 
adequate  for  the  needs  of  the  U.S.S  CARL  VINSON's 
precommissioning  crew,  it  again  proved  too  small  once  the 
ship  was  commissioned  and  became  an  operating  unit  of  the 
U.S,  Navy.  Captain  Martin  then  decided  the  ship  should 
obtain  the  largest  processor  system  made  by  WANG,  a  super 
mini  computer  called  the  VS-100.  This  would  meet  the  ship's 
present  needs  while  allowing  for  future  expansion.  In  July 
1981,  the  VS-80  system  was  returned  to  WANG  in  exchange  for 
a  leased  VS-100  system.  The  VS-100  was  configured  with  a 
spider  network  of  28  smart  terminals  directly  wired  into  the 
mainframe,  tv  288-mb  disk  drives,  one  magnetic  tape  drive, 
one  telecommunications  channel,  and  a  2-mb  main  memory.  By 
October  1984,  the  WANG  VS-100  System  was  purchased  outright 
by  the  ship  and  upgraded  to  include  86  terminals,  21 
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printers,  4  disk  drives,  11  telecommunications  channels, 
8 -MB  of  main  memory,  and  a  prototype  WANG  Net. 

C.  A  SECOND  WANG  VS-80  SYSTEM 

In  January  of  1982  the  management  department  of  the 
U.S.S.  CARL  VINSON  obtained  a  second  WANG  VS-80  System, 
which  had  originally  been  procured  by  the  U.S.S.  Lexington 
(AVT-16).  While  on  board  the  U.S.S.  Lexington,  the  110  Volt 
Alternating  Current  (VAC)  VS-80  System  had  inadvertently 
been  connected  to  a  220  VAC  power  source,  which  resulted  in 
damage  to  a  majority  of  the  internal  electrical  and 
electronic  components.  Once  in  the  possession  of  the  U.^.S. 
CARL  VINSON's  management  department,  repair  parts  were 
procured  from  WANG.  Within  six  months,  technicians  on  board 
the  U.S.S.  CARL  VINSON  had  made  the  system  fully 
operational . 

This  particular  system  was.  installed  in  the  ship's 
Combat  Information  Center  (CIC) .  It  is  configured  with  one 
288-MB  disk  drive,  a  printer,  and  five  smart  terminals 
connected  to  the  CPU  in  a  spider  network.  Neither  the  VS-80 
System  nor  any  of  its  five  workstations  have  external 
communication  capabilities  outside  the  tempest  certified 
space.  The  system  is  being  used  to  handle  highly  classified 
intelligence  information. 

D .  WANG  NET 

In  1983,  the  U.S.S.  CARL  VINSON  was  selected  as  a 
beta- test  site  for  a  prototype  WANG  Net.  The  WANG  Net 
implemented  on  the  ship  actually  consisted  of  two  separate 
nets  (one  upper,  one  lower)  of  the  dual  cable,  broadband, 
active  headend  type  design.  This  means  the  equipment  uses 
two  cables  to  connect  into  the  main  trunk  line.  One  cable  is 
used  for  transmission  and  one  cable  is  used  for  reception, 
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thus  eliminating  the  need  for  two  different  frequencies.  The 
upper  net  serves  all  terminals  located  above  the  hanger 
deck,  while  the  lower  net  serves  all  terminals  located  below 
the  hanger  deck.  It  is  this  lower  loop  that  presented  an 
interesting  engineering  problem  that  required  three 
iterations  of  installation  before  the  net  became  fully 
operational . 

The  main  deck  on  board  a  ship  is  called  the  "damage 
control  deck".  All  compartments  located  below  the  damage 
control  deck  must  maintain  watertight  integrity,  which  means 
that  no  new  penetrations  or  openings  can  be  made  in 
bulkheads  (walls),  overhears  (ceilings),  or  decks  (floors). 
Provisions  are  made  during  the  construction  of  a  naval  ship 
to  provide  a  path  for  cables  and  wires  to  pass  through  these 
inviolate  partitions.  These  paths  are  then  sealed  with  a 
pliant  material  to  maintain  the  compartment's  watertight 
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can  present  problems.  High  voltage  lines,  telephone  wires, 
and  computer  cables  are  all  joined  together  and  run  through 
compartments  and  partitions  as  a  single  group  in  what  is 
called  a  cablerun.  These  cableruns  are  often  routed  near 
light  fixtures,  generators,  and  other  sources  of 
electromagnetic  interference.  It  was  these  cableruns  which 
proved  troublesome  in  the  initial  attempt  to  install  the 
WANG  Net.  The  first  attempt  to  implement  the  system  used 
unshielded  RG-11  coaxial  cable  which  simply  did  not  work. 
CATV-type  amplifiers  installed  at  intervals  along  the  net 
were  also  insufficient  to  keep  signal  attenuation  less  than 
40  DB.  As  a  result,  a  second  attempt  was  made  using  single 
shielded  RG-11  cable  and  a  special  amplifier  designed  to 
keep  signal  loss  to  less  than  40  DB .  While  this  mitigated 
the  problem  somewhat,  it  still  required  a  third  attempt 
before  the  system  was  fully  operational.  On  this  last 
attempt  RG-11  double  shielded  cable  was  installed  along  with 
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some  minor  adjustments  to  the  special  amplifiers,  before  the 
system  became  operational. 

The  current  configuration  of  the  WANG  Net  uses  a 
branching-  tree  topology  to  connect  the  processing  equipment 
to  the  two  single  trunk  lines  that  run  throughout  the  ship. 
Several  amplifiers  and  netmuxs  (network  multiplexers)  are 
attached  to  the  network  cable  at  different  points.  A  netmux 
is  simply  a  device  which  permits  the  simultaneous 
transmission  of  many  independent  channels  into  a  single 
high-speed  data  stream  by  dividing  the  signal  from  different 
device  channels  (terminals)into  successive  alternate  bits. 
In  a  nutshell,  a  netmux  can  be  compared  to  a  black-box  that 
takes  input  data  supplied  by  anywhere  from  1  to  8  terminals 
and  outputs  it  to  the  main  trunk  line  of  the  WANG  Net,  or 
vice  versa.  By  using  a  network  system  such  as  this, 
terminals  and  personal  computers  can  be  easily  attached  to 
the  mainframe  without  the  necessity  of  stringing  a  new  cable 
each  time.  This  results  in  smaller  cableruns  and  better 
watertight  integrity  between  adjoining  compartments,  because 
fewer  cables  penetrate  common  watertight  bulkheads.  It  also 
permits  the  WANG  VS-100  system  to  run  more  than  the  96 
workstations  it  would  have  been  limited  to  had  it  operated 
with  only  the  spider  configuration.  For  each  netmux 
installed  in  the  WANG  Net  an  additional  8  workstations  can 
be  added  to  the  system.  While  there  is  no  limit  to  the 
number  of  netmuxs  that  can  be  installed,  the  present 
operating  system  (VS-OS,  revision  6.2)  on  the  WANG  VS-100 
restricts  the  system  to  a  total  of  128  terminal  nodes. 

E.  ESSENCE  OF  WANG 

Except  for  the  WANG  Net,  the  Wang  VS-100  system  as 
presently  configured  on  board  the  U.S.S.  CARL  VINSON  is  the 
same  system  being  used  in  numerous  commercial  and  industrial 
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applications.  The  essence  of  this  system  is  its  ability  to 
perform  diverse  tasks  of  both  a  general  and  specific  nature. 
It  can  be  used  to  perform  data  processing,  word  processing, 
and  electronic  mail,  yet  still  be  adapted  to  specialized 
use.  An  example  of  this  specialized  use  on  board  the  U.S.S. 
CARL  VINSON  is  the  WANG's  backup  function  as  the  ship's 
message  processing  distribution  system  (MPDS).  The  MPDS  is 
a  system  unique  to  Nimitz  class  aircraft  carriers  and 
communication,  command,  and  control  ships  (LCC's).  It  is  a 
system  that  takes  a  message  received  in  the  ship's 
communication  center,  reads  the  standard  subject 
identification  code  embedded  in  the  header  of  each  message, 
and  routes  it  to  the  action  officer  or  department  that  has 
cognizance  over  that  particular  subject  area.  For  example, 
if  the  subject  concerns  fuel  for  the  ship's  emergency  diesel 
generation  system,  the  engineering  department  would 
automatically  be  routed  a  copy  as  the  message  arrives  on  the 
ship.  What  distinguishes  this  system  from  similar  procedures 
on  other  ships  is  that  MPDS  is  done  electronically  without 
human  intervention.  MPDS  actually  consist  of  a  small 
processor  in  the  communications  center  that  is  linked  to 
several  hardcopy  terminals  dispersed  to  various  functional 
areas  throughout  the  ship,  i.e.  engineering,  supply, 
operations,  etc.  Althougn  MPDS  fully  automates  the 
communicatio’  "■  center  on  board  the  U.S.S.  CARL  VINSON,  a 
separate  paper  tape  punch  creates  a  record  tape  of  each 
message  transaction.  If  the  MPDS  were  to  fail,  the 
information  on  these  paper  tapes  could  be  uploaded  to  the 
WANG  VS- 100  with  an  attached  paper  tape  punch  and 
distributed  to  the  appropriate  departments  and  personnel 
through  the  WANG  terminals.  Mes  ages  can  also  be  composed  on 
the  WANG  VS-1Q0  and  output  on  a  paper  tape.  This  paper  tape 
can  then  be  taken  to  the  ship's  communication  center  and 
transmitted  with  regular  teletype  communications  equipment. 
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The  WANG  VS- 100  is,  therefore 
MPDS. 


a  complete  backup  system  to 


1.  The  User  and  the  WANG  VS- 100 

A  majority  of  present  and  former  personnel  of  the 

U.S.S.  CARL  VINSON  interviewed  about  the  ship's  WANG 

installation  consider  the  VS-100  to  be  user  friendly.  This 
particular  system  is  completely  menu  driven  and  appears  to 
be  easy  to  use.  One  reason  for  this  is  because  it  is  a 
commercial  system  that  was  designed  to  be  used  by  a 
multitude  of  different  users.  A  shipboard  technician  summed 

it  up  when  he  said  "if  you  can  read,  you  can  use  the 

system" . 

2.  Evaluation  of  WANG  on  board  the  U.S.S.  CARL  VINSON 

The  WANG  VS-100  capabilities  that  are  used  the  most 
on  board  the  U.S.S.  CARL  VINSON  are  the  word-processing 
package  and  the  electronic  mail  feature.  One  member  of  the 
ship°s  management  department  estimated  that  90%  of  all  jobs 
performed  on  the  WANG  VS-100  involve  interactive 
word-processing,  while  only  10%  involve  data  processing. 
This  iB  in  consonance  with  one  of  the  two  original  reasons 
for  procuring  the  VS-100  in  the  first  place,  i.e.  to  provide 
the  ship  with  a  powerful,  versatile  word  processing 
capability.  The  other  reason,  which  was  discussed  briefly  in 
an  earlier  part  of  this  chapter,  was  to  aid  in  the  area  of 
planning  and  control. 

Although  the  WANG  VS-100  is  a  centralized  unit,  it 
has  proven  much  more  reliable  than  the  Perq  distributed 
System  discussed  in  Chapter  Three.  There  are  four  primary 
reasons  for  this  phenomenon: 

a.  The  WANG  VS-100  is  a  rugged  machine.  It  is  designed 
to  operate  between  196  vac  (volts  alternating 
current)  and  253  vac  without  sustaining  electronic 
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damage.  Additionally,  a  dedicated  w/30a  circuit 
breaker  is  installed  with  all  WANG  VS-100 
installations  to  shut  the  system  down  in  case  of 
electrical  overload.  [Ref.  33] 

b.  Members  of  the  management  department  ensured  that  an 

isolation  transformer  was  properly  installed  on  the 
ship's  power  outlets  that  supplied  the  WANG  VS-100. 
Although  the  rational  for  an  isolation  transformer  on 
board  ship  is  really  for  electrical  safety  and 
electrical  ground  isolation,  it  has  an  added 

capability  of  attenuateing  electrical  noise  in 
electronic  equipment.  In  addition,  the  ship's  force 
installed  a  low  voltage  protection  device  to  shut 
down  the  system  if  voltage  dropped  too  low.  This 
prevents  the  system  from  voltage  surge  if  power  is 
suddenly  restored  after  a  loss  of  the  electrical 
load. 

c.  A  third  reason  the  WANG  VS-100  proved  so  much  more 

reliable  than  the  Perq  System  is  because  it  is 
enclosed  within  its  own  air  conditioned  space. '  While 
most  of  the  Ferq's  were  also  located  in  air 

conditioned  spaces,  their  spaces  were  more  likely  to 
be  kept  at  a  temperature  and  humidity  conducive  to 
human  comfort  than  that  for  optimum  machine 

performance . 

d.  The  final  reason  the  WANG  fared  so  much  better  than 
the  Ferqs  was  because  the  WANG  mainframe  was  located 
in  a  limited  access  area  where  it  was  constantly 
monitored  by  trained  technical  personnel.  If  an 
abnormal  situation  began  to  develop,  it  could  be 
quickly  detected  and  appropriate  corrective  action 
taken.  With  the  Perq  System,  the  computers  were 
distributed  throughout  the  ship  where  abnormalities 
were  more  likely  to  occur  and  less  likely  to  be 
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detected  by  qualified  technical  personnel.  This 
situation  ultimately  resulted  in  more  equipment 
casualties  to  the  Ferqs. 

Before  October  1984,  the  ship  had  experienced  only 
one  significant  problem  with  the  WANG  VS-100.  A  clock 
circuit  had  failed,  which  in  turn  caused  a  cache  memory 
problem.  Ship's  technicians  corrected  this  problem  within 
two  hours  of  its  occurrence.  The  Perq  computers  on  the  other 
hand  had  suffered  numerous  equipment  problems  throughout 
this  same  time  period. 

a.  Electronic  Mail  and  Word  Processing 

The  combination  of  electronic  mail  and  word 
processing  on  the  WANG  VS-100  have  served  to  reduce  the 
ship's  administrative  work-load  considerably.  One  particular 
area  in  which  this  is  evident  is  in  the  preparation  of 
personnel  evaluations.  Onboard  most  Navy  ships,  a  chief 
petty  officer  would  make  the  first  handwritten  draft  of  an 
enlisted  person's  evaluation.  He  would  then  submit  it  to  his 
division  officer  who  would  either  send  it  back  to  the  chief 
for  revision,  or  submit  it  to  his  department  head.  The 
department  head  would  then  review  the  evaluation  and  either 
send  it  back  to  the  division  officer  for  further  revision  or 
submit  it  to  the  executive  officer  for  final  review  and 
signature  approval.  At  any  point  in  this  process,  changes 
can  be  made  before  it  is  submitted  to  the  next  person  in  the 
chain  of  command,  or  it  can  be  sent  back  down  the  chain  for 
partial  or  total  revision.  Ii  is  not  unheard  of  for  an 
evaluation  to  traverse  through  this  procedure  two  or  three 
times  before  it  is  finally  approved  and  signed.  After  one 
iteration  of  this  traversal  the  evaluation  oftentimes  must 
be  completely  rewritten  or  retyped.  Officer's  fitness 
reports  follow  a  similar  procedure  except  they  are  initiated 
by  the  next  senior  officer  in  the  chain  of  command  and 
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signed  by  the  commanding  officer.  Some  personnel 
required  to  have  evaluations  submitted  on  them  every  six 
months/  while  everyone  receives  at  least  one  a  year  and  two 
if  they  are  being  transferred  off  the  ship.  Multiply  this 
simple  evaluation  process  to  include  the  thousands  of 
personnel  that  make  up  the  crew  of  the  U.S.S.  CARE,  VINSON 
and  the  task  quickly  becomes  non-trivial.  Envision  this 
task  being  performed  on  paper  and  it  becomes  overwhelming. 
With  the  WANG  VS-100  this  same  evaluation  process  is  greatly 
simplified.  The  chief  petty  officer  can  type  in  the  twenty 
or  thirty  evaluations  he  is  required  to  initiate  into  the 
WANG  System  and  send  them  electronically  to  his  division 
officer.  The  division  officer  will  add  his  comments  to  those 
evaluations  he  feels  are  correct  and  forward  them 
electronically  to  his  department  head.  Tho*.  s  that  he  rejects 
are  returned  electronically  to  the  same  chief  petty  officer 
who  initiated  them  for  revision  and  resubmission.  This  same 
process  is  performed  between  the  department  head  and  the 
executive  officer,  and  between  the  executive  officer  and  the 
commanding  officer  for  officer  fitness  reports.  Once  the 
evaluation  has  received  final  approval  from  either  the 
Commanding  Officer  or  the  Executive  Officer,  the  WANG  will 
perform  a  final  spelling  check,  automatically  format,  and 
print  a  hard  copy. 

Although  this  example  concerns  only  the 
shipboard  evaluation  process,  the  method  of  electronically 
creating  and  routing  all  sorts  of  correspondence  and  reports 
is  used  extensively  on  board  the  U.S.S.  CARL  VINSON.  One 
particular  area  where  it  is  used  on  a  daily  basis  is  in  the 
creation  and  release  of  Naval  messages.  The  drafter  will 
initially  create  a  Naval  message  using  the  word  processing 
capabilities  of  the  WANG  VS-100.  These  capabilities  include 
a  spelling  checker,  standard  fill  in  the  blank  type  formats 
for  the  most  commonly  sent  messages,  and  a  plain  language 
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address  (PLAD)  look-up  program  besides  other  standard  word 
processing  features.  The  VS-1QQ  will  look  up  the  correct 
PLAD  and  insert  it  in  the  header  of  the  message.  Once  this 
is  done,  the  message  will  be  routed  to  the  commanding 
officer  for  his  review  and  release.  The  Commanding  Officer 
can  then  review  and  release  the  message  from  the  bridge,  his 
cabin,  or  any  place  on  the  ship  where  a  WANG  terminal  is 
located.  This  precludes  his  having  to  carry  around  a  stack 
of  paper  when  dealing  with  routine  messages,  or  having  to  be 
chased  down  to  get  a  release  signature  in  the  case  of  more 
urgent  ones,  thereby  saving  uncountable  numbers  of  manhours. 
Once  these  messages  are  released  by  the  Commanding  Officer, 
they  are  printed  out  on  a  paper  tape  and  taken  to  the  ship's 
communication  center  for  transmission.  The  combination  of 
electronic  mail  and  word-processing  has  proven  highly 
successful  on  board  the  U.o.S.  CARL  VINSON. 

b.  Data  Processing 

The  VS-100's  data  processing  capabilities  are 
not  being  fully  used  on  board  the  U.S.S.  CARL  VINSON.  One 
reason  for  this  is  because  other  non-tactical  automated 
systems  are  performing  the  majority  of  the  ship' 3  required 
data  processing  tasks.  As  of  October  1984,  a  Durango 
Computer  was  being  used  for  maintaining  records  and  creating 
reports  in  the  food  service  management  area,  while  the 
Honeywell  Snap  I  System  was  being  used  as  an  interface 
between  maintenance  and  supply  functions,  ordering  pai-ts, 
printing  paychecks,  etc.  This  leaves  very  little  data 
processing  actually  being  performed  on  uhe  WANG  V5-10Q. 
There  are  some  exceptions,  however.  One  particular  area  on 
board  the  ship  in  which  the  WANG's  data  processing 
capabilities  are  being  used  is  to  create  customized  reports 
of  ship's  personnel  who  are  eligible  to  vote  in  different 
states  and  elections.  For  example.  If  the  voting  officer 
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needs  to  know  how  many  members  of  the  ship's  engineering 
department  are  eligible  to  vote  in  a  special  election  in 
Michigan,  he  can  process  this  data  on  the  WANG  and  create  a 
customized  report  enumerating  this  information.  The  voting 
officer  can  then  disseminate  the  needed  information  to  the 
appropriate  personnel. 

The  career  counselor  is  another  person  who  uses 
the  data  processing  capabilities  of  the  WANG  VS- 100.  He  is 
responsible  for  maintaining  a  current  list  of  regulations 
and  guidelines  concerning  reenlistment  incentives.  Navy 
schools,  and  general  career  path  information.  The  career 
counselor  will  also  maintain  a  master  schedule  of  career 
interviews,  which  can  be  disseminated  to  division  officers 
on  a  monthly  or  weekly  basis.  This  is  simply  a  list  of 
ship's  personnel  who  are  scheduled  for  division  officer 
reenlistment  interviews.  With  the  WANG  VS- 100 ,  he  is  able  to 
maintain  his  data,  process  it,  and  create  required  reports 
and  interview  schedules  quickly  and  easy.  For  example,  if 
entrance  requirements  for  a  specific  Navy  school  are 
lowered,  the  career  counselor  can  quickly  produce  a  list  of 
ship's  personnel  who  had  previously  expressed  an  interest  in 
that  school,  but  until  now  had  not  met  the  entrance 
requirements.  He  can  then  contact  the  individuals  concerned 
and  ascertain  if  they  are  still  interested  in  attending  the 
school . 

The  ship's  Damage  Control  Assistant  (DCA) 
officer  also  uses  the  data  processing  capabilities  of  the 
WANG  VS-100  to  maintain  the  ship's  master  compartment  check 
off  list  (CCOL) .  Each  compartment  on  the  ship  has  a  CCOL 
posted  in  a  conspicuous  location  near  its  access,  which 
lists  and  describes  all  fittings  and  systems  within  that 
particular  compartment.  The  CCOL  also  gives  the  damage 
control  classification,  which  tells  when  the  fittings  or 
systems  should  be  activated  or  secured,  and  indicates  the 
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ship's  division  that  is  responsible  for  their  maintenance 
and  closure  status.  If  a  division  needs  to  have  a  complete 
list  of  all  the  deck  drains  it  is  responsible  for 
maintaining,  the  DCA  can  produce  such  a  list  from  the  master 
using  the  data  processing  capabilities  of  the  WANG.  Using 
the  WANG's  database,  the  DCA  can  also  produce  a  customized 
report  of  compartment  material  and  equipment  deficiencd.es 
for  each  of  the  last  four  zone  inspections.  Zones  are 
nothing  more  than  artificial  divisions  or  groupings  of 
equipments  and  compartments  to  facilitate  their  inspection, 
hence  the  term  zone  inspection. 

Other  areas  that  use  the  WANG  VS- 100  for  data 
processing  include  the  medical  and  dental  departments.  The 
medical  department  uses  the  system  to  identify  personnel  who 
are  due  for  shots  and  to  monitor  urinalysis  testing  for 
drugs,  while  the  dental  department  identifies  personnel 
requiring  dental  exams.  While  there  is  some  data  processing 
being  performed  on  the  WANG  VS- 100,  it  is  not  enough  to 
justify  the  systems  existence  on  that  basis  alone.  Current 
justification  relies  on  the  areas  of  word™  processing  and 
electronic  mail.  It  has  been  these  two  areas  that  have  been 
the  driving  force  for  increasing  both  the  efficiency  and 
effectiveness  of  numerous  administrative  functions  on  board 
the  U.S.S.  CARL  VINSON. 

c.  Specific  Applications 

With  the  implementation  of  the  WANG  VS-100  on 
board  the  U.S.S.  CARL  VINSON,  an  abundance  of  computing 
power  was  suddenly  made  available  to  ship's  personnel. 
Whila  most  of  the  applications  run  on  the  WANG  by  these 
shipboard  users  is  of  a  general  nature,  many  of  them  proved 
to  be  quite  innovative.  One  of  the  more  novel  uses  of  the 
WANG  VS-100  was  developed  by  the  ship's  first  Commanding 
Officer,  Captain  Richard  Martin,  but  is  actually  employed 
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by  the  ship's  embarked  airwings.  An  airwing  is  a  separate 
organizational  entity  that  is  temporarily  assigned  to  the 
ship  for  an  operational  deployment  or  exercise.  The  airwing 
is  made  up  of  different  squadrons,  which  consist  of  the 
pilots  and  support  personnel  required  to  operate  and 
maintain  a  group  of  like  aircraft.  These  support  personnel 
include  mechanics,  plane-crews,  and  administrative 
personnel.  When  an  airwing  is  assigned  to  the  ship  for  an 
extended  amount  of  time,  it  will  move  all  its  aircraft, 
personnel,  and  records  on  board  the  ship.  These  records  are 
quite  comprehensive.  They  include  everything  from  the 
complete  maintenance  history  of  each  aircraft  to  the  medical 
and.  dental  records  of  the  airwing's  assigned  personnel. 
When  assigned  to  the  U.S.S.  CARL  VINSON,  these  records  are 
carried  on  board  electronically  filed  in  the  airwings 
portable  WANG  Professional  Computer  (PC),  which  they  carry 
with  them.  Each  of  these  portable  computers  is  configured 
with  two  duel  5  1/4  inch  floppy  disk  drives,  a  10  megabyte 
hard  disk  drive,  640-KB  of  random  access  memory,  its  own 
operating  system,  and  a  serial  printer.  Once  on  board,  the 
WANG  PCs  are  connected  to  the  VS-100,  and  all  its  data  is 
uploaded  to  the  mainframe.  While  attached  to  the  U.S.S.  CARL 
VINSON,  the  airwing  uses  the  capabilities  of  the  WANG  VS-100 
to  maintain  files  and  meet  its  data  processing  requirements. 
When  the  airwing  is  ready  to  depart,  it  downloads  its  data 
to  the  WANG  PC,  and  returns  to  its  home  base  with  the  PC  and 
all  it's  files  electronically  recorded.  This  innovative  use 
of  the  ship's  Vs-100  and  a  WANC-  PC  has  permitted  the 
different  airwings  to  automate  their  own  administrative 
functions  and  quickly  integrate  them  into  those  of  the  ship 
when  embarking. 

Another  application  that  has  proven  highly 
successful  on  the  WANG  VS-100  is  the  ship's  personnel 
information  system.  This  is  an  on-line  database.  unique  to 
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the  U , S . S .  CARL  VINSON,  that  contains  medical,  dental,  and 
personnel  records  for  both  ship's  officers  and  enlisted 
crewmembers,  as  well  as,  other  appropriate  administrative 
records.  To  ensure  that  only  properly  authorized  personnel 
can  view  information  within  this  database,  a  Federated 
Management  System  (FMS)  interfaces  with  the  computers 
security  program.  The  FMS  assigns  all  users  a  special  code. 
This  FMS  code  identifies  the  files  and  protection  classes 
(unprotected,  execute-only,  read-only  or  private  file)  that 
can  be  accessed  by  that  particular  user.  When  a  user  first 
logs  on  the  WANG  VS-100,  he  will  enter  his  "user  id"  and 
"personal  password".  From  this  information  the  FMS  will 
internally  locate  his  FMS  code  and  display  a  menu  of  data 
files  that  he  is  allowed  to  access.  Within  the  Personnel 
Management  System  for  example,  only  personnel  authorized  by 
the  medical  department  along  with  those  having  "system 
administrative  rights"  are  allowed  to  read  medical  records. 
All  members  within  the  WANG  division  of  the  management 
department  have  these  "system  administrative  rights", 

This  system  allows  the  personnel  officer  to 
maintain  a  mini  electronic  personnel  record  for  each  member 
of  the  ship's  crew.  In  addition,  the  career  counselor  and 
voting  officer  can  use  this  database  to  create  customized 
reports  a3  previously  discussed,  while  the  ship's  division 
officers  can  use  it  as  an  on-line  division  officers 
notebook.  A  division  officers  notebook  is  nothing  more  than 
a  record  kept  on  each  man  within  a  division.  It  usually 
includes  his  name,  present  rate,  educational  level.  Navy 
schools  attended,  noted  achievements,  etc. 

Additional  application  areas  of  a  specified 
nature  performed  on  the  WANG  VS-100  include  a  messmen 
information  system  to  keep  track  of  messcooks  assigned  to 
the  ship's  messdecks,  a  management  department  utilities  and 
muster  list,  the  public  affairs  officer's  datafiles,  the 
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photographic  departments  equipment  list  and  job  order 
information,  and  a  list  of  navigational  aids  used  by  the 
ship's  navigator. 

d.  Unused  Capabilities 

Although  the  ship  uses  the  VS-100's  word 
processing  and  electronic  mail  applications  extensively  and 
its  data-procesaing  capacity  to  a  limited  degree,  it  is  not 
taking  full  advantage  of  the  WANG-Net  itself.  As  previously 
discussed,  the  WANG-Net  is  of  the  dual  cable  active  header 
type.  Being  a  broadband  network  it  is  capable  of  multiple 
service  analog  transmission,  i.e.  it  is  capable  of 
transmitting  data,  voice,  video,  etc.  vice  strictly  serial 
digital  signaling  as  in  baseband  nets. 

This  capability  allows  the  WANG-Net  to  be  used 
in  the  following  four  ways: 

1.  It  can  be  used  to  support  either  WANG  PC's  or 
intelligent  terminals  as  VS  work  stations.  This  is 
the  mode  in  which  it  is  presently  being  used  on  board 
the  U.S.S.  CARL  VINSON.  These  workstations  just 
input  data  to  the  VS- 100  and  output  it  to  a  CRT 
terminal . 

2.  The  WANG-Net  has  a  remote  telecommunications 
interconnect  band  that  allows  it  to  function  as  a 
telephone  line  between  different  nodes  on  the  net. 
Any  protocol  may  be  used  as  long  as  the  WANG  or 
non-WANG  terminal  devices  using  this  band  have 
industrial  standard  electrical  interfaces,  and  the 
protocols  operate  at  the  same  speed. 

3.  A  special  WANG  PC.  band  is  also  included  which 
connects  all  stand-alone  type  WANG  PC's  into  a 
distributed  network.  The  WANG  VS- 100  cannot  be  part 
of  this  system,  hence  the  distributed  network  will 
still  function  if  there  is  a  casualty  to  the  VS-100 
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itseLf.  This  special  band  uses  time  division 
multiplexing  and  operates  at  2.5  million  bits/second. 
[Ref.  34] 

4.  The  interconnect  band  allows  Stand-alone  PC's  to  talk 
to  each  other  at  either  64,000  bits/sec,  9,600 
bits/sec,  4800  bits/sec,  2400  bits/sec  or  1200 
bits/sec.  This  particular  band  can  also  be  accessed 
by  small  computers  made  by  other  vendors.  [Ref.  35] 
To  use  these  capabilities  more  fully  would 
require  replacement  of  all  intelligent  terminals  presently 
on  the  net  with  either  WANG  PC's  equipped  with  appropriate 
expansion  cards,  or  other  vendor  equivalents  with 

appropriate  protocols. 


E.  A  CRITIQUE  OF  THE  WANG  VS-100  ONBOARD  THE  U.S.S.  CARL 

VINSON 

Being  a  commercial  system  designed  to  accommodate  a  wide 
spectrum  of  users,  the  WANG  VS-100  installation  suffers  from 
the  same  faults  common  to  most  systems  attempting  to  be 
everything  to  everyone.  That  is,  it  does  a  good  job  in  all 
its  shipboard  applications  and  a  superior  job  in  a  few. 
However,  it  may  not  be  the  best  suited  system  for  all  the 
applications  presently  being  performed  on  board  the  ship.  To 
make  a  reasonable  determination  as  to  whether  it  is  the  best 
suited  system  would  require  a  thorough  cost/benefit. 
analysis,  which  goes  beyond  the  scope  of  this  paper.  To  get 
a  oetter  feel  for  the  direction  such  an  analysis  would  take 
some  advantages,  disadvantages,  and  management  issues  will 
be  considered  below. 

1 .  Advantages  o_f  the  WANG  VS-100  Insta liation 

The  WANG  VS-100  System  on  board  the  U.S.S.  CARL 
VINSON  exhibits  many  advantages. 
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a.  Versatile  word  processor.  The  word  processor  that  is 
installed  on  the  ship's  WANG  VS-100  offers  the  user 
several  diverse  capabilities.  These  include  a  choice 
of  fonts,  a  documentation  shrinker,  and  even  the 
capability  to  print  upside  down  if  required. 

b.  User  friendly.  The  management  department  on  board  the 
U.S.S.  CARL  VINSON  holds  a  full  three-day  training 
session  for  new  users  once  a  month  besides  special 
classes  in  basic  and  cobol  programming  when  the  ship 
is  on  an  extended  deployment.  The  monthly  training 
session  itself  consists  of  an  indoctrination  to 
computers  along  with  specific  tutorial  exercises  for 
the  WANG  VS-100  and  the  word  processing  editor.  It 
has  been  the  experience  of  some  members  of  the 
management  department  that  a  student  can  perform 
basic  applications  on  the  VS-100  terminals  after  only 
an  hours  instruction.  The  reason  for  this  is  because 
the  system  is  totally  menu  driven  and  therefore, 
extremely  easy  to  learn  to  use.  The  system  also 
employees  a  library  of  standard  routines  and  utility 
programs  which  make  code  generation  a  simple  task  for 
the  more  sophisticated  user. 

c.  Good  response  time.  The  WANG  VS-100  is  designed  to  be 

an  extremely  fast  machine.  In  addition  to  its 
separate  cache  memory,  the  VS-100  uses  a  64-bit  data 
bus  between  the  main  memory  and  other  major  processor 
components,  and  a  32-bit  central  processor  (CP)  data 
bus.  The  combination  of  these  three  factors  results 
in  a  rapid  CPU  cycle  time  (160 

nanoseconds/micro-instruction) .  With  up  to  70  users 
on  the  system  there  is  virtually  no  noticeable  change 
in  response  time  to  the  user.  Of  course,  because  the 
majority  of  applications  being  run  on  the  processor 
concern  word-  processing  vice  data  processing  means 
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that  the  CPU  is  idle  quite  a  bit  of  the  time.  Thus, 
the  system  usually  runs  near  its  fastest  speed. 

d.  Equipment  reliability.  From  the  time  the  WANG  VS-100 
was  installed  on  board  the  U.S.S.  CARL  VINSON  in  July 
1981  until  the  end  of  the  ship's  first  cruise  in  the 
fall  of  1983,  there  was  only  one  major  equipment 
failure  despite  the  fact  that  most  of  the  equipment 
servicing  was  done  on  board  by  ship's  technicians. 
Since  the  end  of  that  first  cruise  there  have,  been  no 
significant  equipment  casualties  reported  for  the 
ship’s  WANG  VS-100. 

e.  Diverse  selection  of  software  readily  available. 
Being  a  commercial  system,  the  VS-100  can  support  a 
wide  range  of  off—  the— shell  software  along  with 
several  multiple  high-level  languages,  including  ANSI 
COBOL,  BASIC,  FORTRAN,  PL/1,  and  RPG  II.  In  addition, 
it  supports  a  macro  assembler  that  uses  an 
instruction  set  compatible  with  that  used  on  an  IBM 
360,  and  an  English-like  command  language  called 
"PROCEDURE",  which  allows  the  user  to  create  special 
text  files  that  will  perform  many  of  the  operations 
normally  executed  interactivi ly .  It  is  similar  to  job 
control  language.  [Ref.  36] 

2.  Disadvantages  of  the  U.S.S.  CARL  VINSON' s  WANG 
Installation 

The  WANG  VS-100  System  exhibits  many  disadvantages 
as  it  is  presently  installed  on  board  the  U.S.S.  CARL 
VINSON.  These  include  the  following: 

a.  Lack  of  redundancy.  Being  a  centralised  system  with  a 
single  CPU,  the  e  is  no  backup  if  a  major  casualty 
were  to  occur  to  the  equipment.  This  could  be 
mitigated  somewhat  by  replacing  all  the  intelligent 
terminals  on  the  WANG  Net  with  self  contained 
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personal  computers  configured  with  appropriate 
expansion  cards  to  activate  the  distributed 
processing  capacity  of  the  WANG-Net  as  discussed 
above . 

b.  Requires  a  constant  attendant  24  hours  per  day. 

Unlike  the  Perqs  and  the  Snap  II  computers  being 
implemented  on  smaller  ships,  the  WANG  VS-100 

requires  an  operator  to  be  on  duty  within  the  space 
at  all  times.  This  attendant  is  required  for  security 
as  well  as  for  equipment  operation  and  monitoring. 

c.  Limited  growth  potential.  The  present  system 
architecture  is  set,  limiting  flexibility  for  future 
growth  to  128  terminals.  While  the  present  system 
cannot  be  expanded  beyond  these  128  terminal  nodes, 
replacement  of  all  intelligent  terminals  on  the 
WANG-Net  with  stand-alone  PC's  configured  with  the 
appropriate  expansion  boards  would  increase  the 
amount  of  processing  that  could  be  done  with  the 
present  configuration.  This  would  postpone  if  not 
preclude  having  to  go  to  a  larger  machine  as  new  uses 
for  the  VS-100  are  developed. 

d.  Lack  of  an  uninterruptible  power  supply  (UPS). 

e.  Onboard  a  Naval  vessel  it  is  considered  good 

engineering  practice  to  rotate  ship's  service  turbo 

generators  (SSTG's)  on  a  daily  basis  to  ensure  that 
all  mechanical  systems  wear  at  approximately  the  same 
rate,  as  well  as,  to  detect  abnormal  operating 
conditions  in  any  of  the  equipment.  While  this 
shifting  of  generators  is  usually  carried  out  in  a 
smooth,  orderly  procedure,  it  is  not  uncommon  to  lose 
electrical  power  in  all  or  parts  of  the  ship.  When 
this  occurs,  all  electronic  equipment  that  does  not 
have  an  UPS  must  be  secured  to  prevent  internal 

damage.  The  WANG  VS-100  does  not  have  a  UPS  which 
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means  that  it  will  shut  down  in  case  of  a  power 
interruption.  This  results  in  the  loss  of  any  data 
then  being  input  on  the  intelligent  terminals, 
unscheduled  down-time,  and  a  time  consuming  procedure 
to  reset  the  system  and  bring  it  back  on-line. 

f.  Lost  data  if  CPU  shuts  down.  If  the  CPU  should  be 
inadvertently  shut  down  through  a  power  loss  or  some 
other  mishap  it  loses  the  addresses  of  the  terminals 
that  are  inputing  data  at  that  time.  This  means  that 
all  the  data  in  the  buffers  of  the  intelligent 
terminals  cannot  be  recovered. 

g.  Reliance  on  one  vendor.  The  WANG  VS-100  system  and 
associated  WANG  Net  as  implemented  on  the  U.S.S.  CARL 
VINSON  is  a  100%  WANG  system.  Since  many  commercial 
devices  and  peripheral  equipments  are  not  compatible 
with  the  VS-100,  they  must  be  purchased  from  WANG 
vice  competitive  bidding.  Hence,  the  ship  is  locked 
into  using  WANG  equipment  with  very  few  exceptions. 

h.  Lack  of  Navy  parts  support  for  the  VS-100.  Since  the 
WANG  VS-100  is  not  a  standard  system  throughout  the 
Navy,  it  is  not  supported  by  the  Naval  supply  system. 
This  means  that  the  ship  is  required  to  purchase  and 
carry  numerous  replacement  parts  and  consumable  items 
on  its  own.  The  ship  is  presently  carrying  an 
estimated  one-time  expenditure  of  $475,000  in  repair 
parts  and  is  expending  $100,000  per  year  in 
consumables  to  support  the  WANG  VS-100. 

3  -  Management  Issues 

In  addition  to  those  advantages  and  disadvantages 
enumerated  above,  there  are  several  issues  that  do  not  fit 
clearly  into  either  category.  These  are  issues  that  should 
be  considered  before  the  decision  to  acquire  and  install  a 
processing  system  is  even  made.  For  the  most  part  they  are 
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management  issues  of  which  only  five  will  be  addressed  in 
this  chapter. 

a.  Need  and  purpose.  Although  the  justification  for 

installing  the  original  System-20  on  board  the  U.S.S. 
CARL  VINSON  was  to  satisfy  a  perceived  need  in  the 
area  of  planning  an  control,  a  comcommitant  purpose 
for  the  small  WANG  processor  was  never  clearly 
defined.  This  failure  to  fix  and  control  the  specific 
applications  that  should  be  run  on  the  WANG  System-20 
resulted  in  its  being  used  in  several  ways  that  had 
little  to  do  with  planning  and  control.  To  complicate 
the  situation  even  more,  the  coterie  of  users  was 
expanded  to  include  the  ship's  department  heads.  The 
combination  of  expanding  the  number  of  users  and 
allowing  new  applications  to  be  placed  on  the  system 
resulted  in  an  increase  in  demand  that  was  beyond 
the  capability  of  the  System-20  to  fulfill.  To  meet 
these  demands,  the  ship  began  a  series  of  upgrades. 
Each  upgrade  replaced  a  predecessor  that  had  failed 
to  satisfy  the  ship's  insatiable  demand  for 

processing,  until  the  VS-100  was  installed  in  July 
1381.  If  a  thorough  requirements  analysis  had  been 
performed  on  board  the  U.S.S.  CARL  VINSON  before  the 
procurement  of  the  first  System-20,  the  true  needs  of 
the  ship  could  have  been  recognized.  This  in  turn 
would  have  resulted  in  a  more  efficient  and  effective 
method  of  acquiring  a  suitable  processing  system  for 
the  ship . 

b.  Life  Cycle  cost.  Prior  to  investing  in  an  actual 
processing  system  such  as  the  WANG  VS-100,  an 
economic  feasibility  study  should  be  conducted  in 
order  ascertain  if  the  system  is  too  expensive  for 
the  benefits  it  will  provide.  This  is  usually 
determined  by  a  thorough  cost/benefit  analysis. 
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There  is  no  evidence  that  a  cost/benefit  analysis  was 
ever  performed  on  any  of  the  WANG  Systems  installed 
on  board  the  U.S.S.  CARL  VINSON.  Two  different 
members  of  the  ship's  management  department  made  the 
comment  during  an  interview  that  much  of  the  software 
for  the  VS-1QQ  was  free,  i.e  it  was  provided  by  WANG 
when  the  system  was  installed.  While  initial  cost  may 
have  been  zero,  the  maintenance  cost  must  still  be 
considered.  Another  member  of  the  management 
department  indicated  that  consumable  supplies  (Disk 
packs,  tapes,  etc.)  are  costing  approximately 
$100,000  a  year.  In  addition,  $475,000  in  repair 
parts  were  bought  for  the  WANG  VS- 100  during  FY  1984. 
These  parts  were  not  used,  but  placed  in  storerooms 
in  the  event  they  are  needed.  These  are  just  a  few  of 
the  cost  that  should  have  been  considered  before 
system  implementation.  Although  other  cost  figures 
were  unavailable  it  would  not  have  been  difficult  to 
work  up  a  reasonable  life-cycle  cost  estimate  before 
making  the  decision  to  implement  the  system.  The 
benefit  side  is  much  more  difficult  to  quantify.  In 
addition  to  the  advantages  discussed  earlier  in  this 
chapter,  the  WANG  VS- 100  System  has  undoubtedly 
streamlined  several  operations  on  board  the  ship 
which  has  resulted  in  the  savings  of  thousands  of 
manhours.  Some  of  these  manhours  could  be  quantified 
and  translated  into  dollars,  while  others  that  cannot 
be  identified  result  in  improved  administrative 
operations  for  the  ship  as  a  whole.  It  would  not  be 
unreasonable  to  find  that  the  savings  were  actually 
as  high  or  higher  than  the  cost, 
c.  Operational  feasibility.  This  is  concerned  with  the 
effect  the  system  will  have  ori  the  people  who  are 
going  to  use  it,  and  in  turn  the  effect  the  people 
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will  have  on  the  system.  The  effect  that  ship's 
personnel  had  on  the  expansion  of  the  WANG  Systems  on 
board  the  U.S.S.  CARL  VINSON  has  been  discussed 
throughout  this  Chapter.  However,  the  effect  the 

system  had  on  ship's  personnel  and  other  systems  is 
just  as  dramatic.  For  example,  two  major  concerns  in 
this  area  are  job  displacement  and  manning 
considerations.  As  of  October  1984,  there  were  11 
personnel  assigned  to  the  WANG  division  within  the 
management  department.  Three  of  these  personnel  were 
petty  officers  and  two  of  them  were  designated 
strikers  in  the  data  processing  rating.  This  means 
that  six  of  the  eleven  personnel  were  recruited  from 
other  divisions  within  the  ship  to  work  in  the  WANG 
division,  three  personnel  that  had  been  assigned  to 
the  ship  for  the  Snap  program  had  been  placed  in  the 
WANG  division,  and  two  personnel  were  either 
recruited  from  another  division  on  board  the  ship  or 
taken  out  of  the  ship's  Snap  II  manpower  complement. 
This  raises  an  interesting  question  as  to  whether  the 
Snap  division  on  the  U.S.S.  CARL  VINSON  is  being 
adversely  affected  by  having  five  technicians  that 
were  originally  assigned  to  the  ship  as  part  of  the 
Snap  I  program  actually  working  in  the  WANG  division. 
Whatever  the  case,  this  type  of  manning  decision  was 
dictated  as  a  direct  result  of  the  WANG's  rapid 
expansion  and  lack  of  Navy  manpower  support  for  the 
WANG  system.  The  issues  to  be  considered  under 
operational  feasibility  must  therefore  address  the 
impact  a  particular  system  will  have  on  other 
shipboard  systems  by  creating  an  increased  demand  for 
scarce  resources  such  as  technical  manpower, 
d.  Security  issues.  Security  issues  must  be  addressed 
and  dealt  with  throughout  the  life  of  the  system.  In 
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an  environment  such  as  exist  on  board  the  U.S.S.  CARL 
VINSON,  where  sensitive  and  classified  information  is 
prevalent  in  virtually  every  department,  security  of 
information  is  paramount.  The  engineering  department, 
which  had  originally  been  using  the  VS--10G,  has  moved 
most  of  its  files  to  a  WANG  PC  to  prevent  a  possible 
•  compromise.  Likewise,  the  VS-80  System  located  in 
the  combat  information  center  is  completely  isolated 
to  prevent  the  .  compromise  of  highly  classified 
information. 

Security  of  unclassified  information  must  also  be 
considered.  While  the  WANG  VS-100  has  an  extensive  security 
system  that  n  quires  both  a  code  and  a  password,  besides  the 
federated  management  system  previously  discussed,  the 
system  has  two  ways  in  which  security  can  be  bypassed.  The 
first  way  is  to  obtain  system  administration  rights.  All 
members  of  the  WANG  division  are  granted  these  rights,  which 
allows  them  to  access  any  files  within  the  system.  To  reduce 
the  potential  for  abusing  this  privilege,  certain 
precautions  can  be  taken.  One  such  precaution  is  to  ensure 
that  all  personnel  given  system  administration  rights  come 
under  the  purview  of  the  Navy's  Personnel  Reliability 
Program  (PRP).  This  is  a  program  which  certifies  personnel 
who  are  required  to  work  with  sensitive  information  or 
equipment.  It  is  not  clear  whether  the  PRP  was  used  within 
the  management  department  on  board  the  U.S.S.  Carl  Vinson. 
The  second  way  that  unauthorized  entry  to  sensitive 
information  could  occur  is  by  monitoring  the  cables 
connecting  the  peripheral  devices  and  terminals  to  the  CPU. 
Since  all  cables  connecting  remote  terminals  or  PC's  run  in 
open  cableruns,  often  through  unmanned  compartments,  they 
could  be  monitored  at  numerous  points  with  equipment  that  is 
readily  available  on  board  ship.  Using  this  technique, 
someone  bent  on  malicious  destruction  or  sabotage  of 
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information  could  easily  obtain  the  frequencies  generated  by 
authorized  users  logging  into  the  system,  and  later 
duplicate  these  same  frequencies  to  access  files.  Security 
is  an  issue  that  must  be  addressed  before  a  system  is 
procured,  as  well  as,  throughout  its  entire  life-cycle. 

G.  CONCLUSIONS 

The  implementation  of  the  WANG  VS- 100  System  on  board 
the  U.S.S.  CARL  VINSON  was  perhaps  done  too  quick.  Instead 
of  doing  a  requirements  analysis  and  then  selecting  the 
system,  the  system  was  selected  and  applications  developed 
after  the  fact.  While  backwards,  this  method  does  have  its 
advantages.  The  primary  one  is  that  it  allows  the  user  to 
experiment  with  novel  ways  in  which  to  use  the  system. 
Sometimes  a  new  and  innovative  application  is  developed  that 
serves  to  justify  system  cost  better  than  those  applications 
for  which  the  system  was  intended. 

Many  of  the  disadvantages  of  the  VS- 100  are 
disadvantages  only  because  the  system  is  not  standardized 
and  supported  by  the  Naval  supply  system.  This  is  the  reason 
the  ship  had  to  procure  and  stock  repair  parts  costing 
$475,000.  Had  the  WANG  VS-  100  been  a  common  system  within 
the  fleet  supported  by  the  Naval  supply  system,  the  ship 
would  not  have  had  to  tie  up  so  much  money  in  repair  parts. 

The  WANG  is  a  reliable  system  as  demonstrated  by  its 
lack  of  significant  casualties  on  board  the  U.S.S.  CARL 
VINSON,  but  this  very  reliability  could  result  in  future 
problems  for  the  ship.  Personnel  on  the  U.S.S.  CARL  VINSON 
are  becoming  too  dependent  on  the  system.  As  more 
applications  are  added  tc  the  system,  it  will  become  even 
more  indispensable  to  the  ship.  On  the  other  hand,  as  the 
system  ages  it  will  likely  become  less  reliable.  Parts  will 
begin  to  wear  or  deteriorate  and  the  system  will  likely 
experience  increased  downtime. 
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IV.  SNAP 


A.  INTRODUCTION 

The  Shipboard  Non-t.actical  Automated  Data  Processing 
Program  (SNAP)  was  designed  to  provide  surface  ships  and 
submarines  of  the  U.S.  Navy  with  a  standard,  information 
management  system.  This  program  has  three  primary  purposes: 

1.  Reduce  the  ever  growing  Administrative  work- load 
associated  with  maintenance,  supply,  financial 
management,  and  personnel  administration. 

2.  Provide  a  responsive,  flexible  facility  for  shipboard 
management. 

3.  Improve  the  accuracy  and  timeliness  of  ships'  reports 
to  other  commands,  without  increasing  the  ships' 
administrative  work- load. 

The  original  goal  of  the  SNAP  program  was  to  meet  the 
Chief  of  Naval  Operation's  (CNO's)  Objective  Number  5  cf 
1980.  .  This  objective  was  intended  to  alleviate  "the 
administrative  burden  on  fleet  units."  [Ref.  37]  The  SNAP 
concept  has  been  developed  as  two  separate  programs.  SNAP  I 
for  larger  ships  of  the  fleet,  and  SNAP  II  for  smaller 
surface  ships  and  submarines. 

1.  SNAP  I  System 

The  SNAP  I  non-tactical  computer  system  is  the 
replacement  for  the  AN/UYK-5(V)  system  which  has  been  in  use 
in  the  fleet  and  in  Marine  Air  Groups  since  the  mid-1960's. 
SNAP  I  is  designated  the  AN/UYK-65 (V) ,  non-tactical  ADP 
system.  Eventually  all  the  larger  ships  of  the  Navy  will 
have  SNAP  I  systems  installed,  including  the  carriers, 
repair  ships,  supply  ships,  and  amphibious  ships,  and  the 
Marine  Air  Groups  (MAG) . 
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SNAP  I  started  in  1974  when  a  plan  was  approved  for 
the  replacement  and  upgrade  of  the  AN/UYK-5(V)  system,  which 
by  then  was  obsolete  and  experiencing  maintenance  problems. 
A  two  stage  implementation  plan  was  finally  approved  in  May 
1977. 

The  first  step  included  the  replacement  of  several 
hardware  units,  including  tape  drives  and  line  printers  that 
had  been  experiencing  many  maintenance  and  operational 
problems.  This  step  was  completed  in  May  1980.  The  second 
step  in  the  implementation  process  included  the  replacement 
of  the  remaining  hardware  with  commercially  acquired, 
off-the-shelf,  processing  equipment.  This  was  paralleled  by 
an  upgrade  in  application  software  to  handle  on-line,  real 
time  processing. 

Honeywell  Information  Systems  International  Inc., 
was  selected  as  the  prime  contractor  for  SNAP  I  in  June 
1982.  The  Honeywell  DPS-6  series  computers  are  installed  as 
a  distributed  processing  system  and  are  arranged  in  one  of 
four  basic  configurations  depending  on  the  mission  and  type 
of  each  ship.  [Ref.  38]  A  total  of  up  to  221  DP-6  systems 
are  to  be  purchased  for  installation  on  67  ships,  17  MAGs, 
and  26  selected  shore  sites  (SIMAs,  training  sites.  Naval 
Air  Stations,  etc.)  All  the  shipboard  equipment 

installations  are  to  be  completed  during  fiscal  year  1985 
[Ref.  39].  The  projected  life-cycle  costs  for  the  SNAP  I 
system  are  estimated  to  be: 

1.  Software  Development  Costs  $127,389,000 

2.  Software  Maintenance  Costs  $319,914,000 

3.  Hardware  Acquisition  Costs  $420,600,000 

4.  Ship  Alteration/Installation  Costs  $  74,307,000 

[Ref.  40] 

By  October  1984,  seventeen  of  the  eighty-five  phase 
two  equipment  replacements  had  beed  completed.  Many  of  the 
real-time  (RT)  application  programs  were  being  tested  in 
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fiscal  year  1984  and  were  scheduled  to  be  implemented  during 
the  following  two  years.  Until  these  programs  are  ready,  the 
AN/UYK-65(V)  systems  have  been  emulating  the  AN/UYK-5(V) 
computers,  processing  data  in  batch  mode,  with  key  to  disk 
data  entry.  (Ref.  41] 

2.  SNAP  II  System 

SNAP  II  systems  are  scheduled  for  installation  on 
452  ships  between  the  fiscal  years  1983  through  1988.  The 
basic  philosophy  behind  SNAP  ! I  is  to  provide  a  system  that 
is  centrally  procured,  designed  and  managed,  which  can  be 
operated  and  maintained  by  users  who  have  little  knowledge 
of  computers.  This  is  difierent  from  the  SNAP  I  systems, 
which  require  a  a  staff  of  computer  technicians  and 
operators.  The  SNAP  II  systems  are  designed  to  be  highly 
reliable,  requiring  a  minimum  of  shipboard  maintenance  and 
repair.  The  premise  underlying  this  concept  is  that  no 
additional  shipboard  personnel  are  required  for  the 
operation  and  maintenance  of  the  SNAP  II  system!  Instead, 
personnel  already  assigned  to  the  ship  with  appropriate 
technical  backgrounds,  i.e.  Electronic  Technicians  (ET) 
will  be  trained  to  operate  and  maintaiii  the  system.  They 
will  perform  these  duties  on  a  collateral  basis  along  with 
their  primary  duties.  Thus,  SNAP  II  computers  are  designed 
to  run  without  operators  in  an  unmanned  space,  while  users 
interact  with  the  computer  via  remote  terminals  at  various 
locations  throughout  the  ship. 

The  SNAP  II  systems  use  application  programs  written 
in  COBOL,  but  allows  the  users  to  write  and  run  their  own 
programs  in  BASIC,  MUSE  IV  word-processing  language,  or  A2-7 
report/query  generator  language.  The  application  software, 
provided  and  maintained  by  the  Navy  Management  Support 
Systems  Office  (NAVMASSO),  cannot  be  directly  interfaced  or 
accessed  by  user  generated  COBOL  applications.  This 
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limitation  is  intended  to  protect  against  intentional  or 
inadvertent  modification  of  the  SNAP  II  application  software 
and  databases. 

The  hardware  used  in  the  SNAP  II  systems,  designated 
AN/UYK-62 (V) ,  comes  in  one  of  four  standard  configurations 
depending  on  ship  type  and  class.  SNAP  II  systems  use  Harris 
series-300  minicomputers  and  other  commercial 
"off-the-shelf"  peripheral  equipment  ruggedized  for 
shipboard  use. 

While  the  SNAP  I  and  SNAP  II  systems  have  different 
hardware  architecture,  they  have  similar  software  design 
specifications,  with  some  of  the  application  software 
capable  of  running  on  both  systems  with  only  minor 
modifications.  The  application  software  is  designed  and 
developed  by  the  NAVMASSO,  who  is  the  Central  Design 
Activity  (CDA)  for  both  systems.  Because  of  these 
similarities  in  the  management  and  functionality  of  the  two 
systems,  only  SNAP  II  will  be  reviewed  in  greater  depth  .  It 
is  the  design,  development  and  management  of  this  SNAP  II 
system  that  is  the  focus  of  this  chapter. 

B .  BACKGROUND 

SNAP  II  systems  are  intended  to  provide  the  smaller 
surface  ships  and  submarines  with  an  automated  data 
processing  capability. 

One  main  problem  faced  by  shipboard  commanding  officers, 
has  been  the  ever-growing  administrative  and  management 
burden  placed  on  their  ships. 

"The  continued  emphasis  on  decreased  shipboard  manning 
levels  has  traditionally  addressed  only  the  operational 
requirements  and  overall  impact  on  shipboard  combat 
readiness.  The  Commanding  Officer,  however,  has  few 
tools,  beyond  personal  leadership  to  cope  with  the 
administrative  burden.  [Kef.  42 J 
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This  problem  has  been  the  theme  of  several  research  studies 
over  the  past  decade.  The  SNAP  II  system  represents  the 
culmination  of  that  research  for  improving  productivity  in 
the  fleet. 

1.  The  U.S.S.  DAHLGREN  Study 

In  August  1972,  the  Chief  of  Naval  Operations 
(OP-91)  directed  a  study  into  the  potential  use  of  automated 
data  processing  on  board  combatant  sh'ps  to  support 
maintenance  and  material  management  (3-M),  personnel 
administration,  and  supply.  The  U.S.S.  DAHLGREN  (DLG-12) 
was  selected  as  the  site  for  this  study.  [Ref.  43]  The 
non- tactical  ADP  system  installed  and  tested  on  U.S.S. 
DAHLGREN  in  January  1973  was  a  Data  General  NOVA  1200 
"minicomputer"  with  a  32k-word  core  memory,  one  printer,  one 
teletype,  a  disk  system,  and  four  CRTs.  The  operating  system 
supported  a  limited  multi-user  environment,  which  used  a 
swapping  mode  of  time  slicing.  It  also  supported  the  BASIC 
programming  language,  The  application  software  developed 
and  implemented  during  the  study  was  Computer  Integrated 
Instruction  (Cl  I)  and  Shipboard  Training  Administration 
System  (STAS).  C1I  was  an  online  training  program  for 
shipboard  instruction  in  General  Damage  Control,  while  STAS 
was  used  to  manage  a  personnel  training  database  system  as 
well  as  a  Personnel  Qualification  Standard  (PQS)  tracking 
system.  Both  systems  were  developed  aff-3hip  by  Naval 
Personnel  Research  and  Development  Center  (NPRDC)  and 
installed  and  prototyped  on  board  the  U.S.S  DAHLGREN. 
[Ref.  44]  From  the  study  report,  issued  in  December  1974, 
four  primary  conclusions  can  be  drawn: 

a.  Commercial  off-the-shelf  hardware  can  effectively  be 
used  in  the  harsh  environment  of  the  small  combatant. 

b.  The  off- ship  development  of  software  by  the  Navy 
Personnel  Research  and  Development  Center  (NPRDC) 
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proved  to  be  a  highly  effective  method  of  providing 
high  quality  application  software  without  increasing 
the  work  load  for  shipboard  personnel. 

c.  There  were  not  enough  CRT  terminals  and  teletypes  to 

adequately  support  the  training  and  management 

applications . 

d.  The  use  of  computer  systems  for  shipboard 

non-tactical  applications  was  shown  to  be  an 
effective  means  to  improve  productivity  in  damage 
control  training  and  in  training  management. 

After  several  primary  users  of  the  NOVA  1200  system  were 
transfered  to  other  commands  the  system  fell  into  disuse. 
As  a  result  of  this  disuse  and  the  lack  of  ’’command 
attention",  the  NOVA  1200  system  was  removed  from  the  ship 
in  December  1974. 

2.  The  U.S.S.  GRIDLEY  Study 

In  early  1975,  the  U.S.S.  GRIDLEY  (CG-21)  was  chosen 
for  a  second  study  to  be  conducted  under  the  direction  of 
NPRDC .  Using  the  Data  General  NOVA  1200  mini -computer 
system,  NPRDC  implemented  19  management  applications  that 
were  previously  developed  for  U.S.S.  DAJJLGREN.  The  programs 
were  so  successful  that  in  1978  the  Data  General  system  was 
replaced  with  a  larger,  more  capable  Digital  Equipment 
Corporation,  PDP  11/60  computer  system.  The  new  system 
supported  Pascal,  BASIC  Plus,  Fortran  IV,  and  COBOL  in  a 
multi-user  environment.  Because  the  U.S.S  GRIDLEY  already 
had  data  systems  technicians  assigned  in  addition  to  the 
dedicated  personnel  working  on  the  system,  they  were  soon 
running  ship  developed  applications,  which  included 
automating  a  23,000  line  item  supply  inventory,  the  crew's 
personnel  records,  and  the  Coordinated  Ship's  Maintenance 
Project  (CSMP).  [Ref.  45] 
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While  several  conclusions  can  be  drawn  from  the 
lessons  learned  in  the  U.S.S.  GRIDLEY  study,  one  point  was 
clear  from  the  onset.  Command  "support  and  interest"  made 
the  difference  between  success  and  failure.  Other 

conclusions  of  the  study  [Ref.  46],  include: 

a.  Shipboard  personnel  are  capable  of  developing 

applications  that  effectively  reduce  the  manual 
work- load,  but  the  time  required  to  do  so  is 

prohibitive:,  and  the  results  are  not  of  equal  quality 
for  all  commands.  The  real  payoffs  come  in  the 
treinsfer  of  operating  application  software  to  other 
commands,  without  additional  development  costs. 

b.  Off-the-shelf  commercial  hardware  could  be  used  to 
provide  automated  data  processing  on  board  small 
combatants  despite  the  harsh  environment  of  salt  air 
and  constant  movement  due  to  the  ship's  pitching  and 
rolling. 

c.  Major  supply  functions,  like  inventory  material 
management  of  on  board  repair  parts,  could  be 
maintained  on  hard  disk  drives,  requiring  only  3-4 
megabytes  of  disk  memory. 

3-  The  U.S.S.  C00NT2  and  U.S.S.  RADFORD  Study 

In  March  1980,  the  Commander  Surface  Forces  Atlantic 
Fleet  (COMNAVSURFLANT)  authorized  a  NPRDC  study  on  the 
shipboard  use  of  microcomputers  for  word  processing  and 
other  data  management  applications.  The  U.S.S.  COONTZ 
(DDG-40)  and  the  U.S.S.  RADFORD  (DD968)  were  chosen  as  sites 
for  the  study.  Alpha  Micro  AM-1031,  microcomputers  with  256 
KB  main  memories,  and  16-bit  central  processing  units  were 
leased  and  installed.  The  . systems  included  Winchester  10 
megabyte  hard  disks,  video  display  terminals,  and  printers. 
All  were  connected  with  standard  three  pair  shielded  cable. 
A  data  management  system,  called  AMS  developed  by  Applied 
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Micro  Systems  LTD.,  and  a  word  processing  system,  called 
ALPKAWORD,  were  provided  with  the  leased  systems.  These 
systems  used  a  multi-user,  multi-tasking  operating  system, 
handling  up  to  six  users  at  a  time.  Power  was  provided  by  60 
Hz  voltage  transfc rmers . 

During  the  one  year  study  there  were  no  system 
malfunctions,  even  though  both  ships  made  extended  six  month 
deployments,  subjecting  the  systems  to  high  seas, 
temperatures  of  85-95  degrees,  and  humidity  between  75-85%. 
This  demonstrated  the  high  reliability  of  commercial, 
off-the-shelf  hardware  in  the  shipboard  environment.  Each 

ship  had  two  maintenance  men  who  had  received  only  two  weeks 

* 

of  training  in  system  maintenance.  [Ref.  47] 

Although  more  than  80  data  management  applications 
and  200  word  processing  applications  were  developed,  there 
was  a  significant  difference  in  the  use  of  the  Alpha  Micro 
systems  by  the  two  ships.  On  the  U.S.S  COONTZ,  the 
Commanding  Officer  became  heavily  involved,  acting  as  the 
head  systems  analyst.  He  had  his  data  systems  technicians 
chief  (DSC)  spending  45%  of  his  time  on  the  system.  The  ship 
made  extensive  use  of  both  the  data  management  system  (DMS) 
and  the  word  processing  systems.  On  the  other  hand,  U.S.S. 
RADFORD  assigned  a  data  systems  technician  second  class 
(DS2)  to  maintain  and  operate  the  system  on  a  collateral 
duty  basis.  Although  the  wrord  processing  application  was 
well  used,  few  DMS  applications  were  developed, 
demonstrating  that  the  quality  of  shipboard  software 
development  is  proportional  to  the  amount  of  attention  and 
support  provided  by  the  command.  (Ref.  48] 

The  conclusions  of  this  study  provided  a  valuable 
insight  into  the  use  of  microcomputers  for  shipboard 
non-tactical  automated  data  processing.  The  primary  lessons 
learned  were  [Ref.  49]  : 
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a.  The  use  of  computers  has  a  significant  impact  on 
reducing  the  administrative  work-load  in  the  fleet 
and  contributes  to  operational  efficiency. 

b.  Data  management  applications  can  be  developed  by 
shipboard  personnel,  but  only  with  significant 
command  support  and  manpower. 

c.  Many  commercially  available  microcomputers  are 
reliable  and  compatible  v/ith  the  shipboard 
environment . 

d.  Six  keyboard  video  display  terminals  ( KVDT )  provided 
with  the  systems  were  insufficient  to  adequately 
support  data  entry. 

Although  the  study  was  completed  after  much  of  the  SNAP  II 
planning  had  been  done,  it  supported  the  viability  of  the 
SNAP  II  concept.  It  also  addressed  the  need  to  deal  with  the 
proliferation  of  microcomputers  in  the  fleet. 

4.  SNAP  1 1  Concept  Development 

In  1978,  the  conceptual  iaea  of  SNAP  II  was 
approved.  The  Mission  Element  Needs  Statement  (MENS)  for  the 
system  was  approved  in  May  1980.  It  outlined  the  requirement 
for  an  automated  system  to  reduce  the  administrative  burden 
on  the  fleet.  The  proposed  program  was  to  be  a  centrally 
managed  and  coordinated  effort  to  provide  non-tactical 
automated  support  to  every  ship  in  the  fleet.  The 

philosophy  was  that  functional  requirements  and  interface 
requirements  were  the  "same"  for  all  ship  types,  even  though 
the  hardware  requirements  might  differ.  Therefore,  a 
standard  Management  Information  System  (MIS)  could  be 
created  around  these  same  functional  specifications. 
[Ref.  50] 

In  1979,  the  Automated  Data  System  (ADS)  development 
plan  was  written.  It  was  reviewed  by  the  various  functional 
sponsors  and  fleet  commands.  Based  on  this  ADS  plan,  SNAP 
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II  was  prototyped,  using  leased  WANG  VS-80  computer  systems 
and  peripherals,  and  application  software  developed  by  the 
Navy.  The  purpose  of  prototyping  was:  1)  to  prove  the 
viability  of  the  SNAP  II  concept,  and  2)  to  refine  the 
"concepts  and  strategies  preparatory  to  seeking  authority  to 
develop  the  Automated  Information  System  (AIS)"  [Ref,  51J. 

The  Functional  Description  for  the  SNAP  II, 
Shipboard  Data  System  (SDS)  was  issued  in  March  1981,  by 
NAVMASSO,  with  the  overall  goal  of  automating  six  primary 
functional  areas.  See  Table  II  . 


TABLE  II 

SNAP  II 

Functional  Areas 

1 .  Supply 

4.  Maintenance 

2.  Pay/Di sbursing 

5.  Personnel 

3.  Administration 

6.  Medical/Dental 

Since  SNAP  II  was  designed  to  be  run  by  users  with 
minimal  computer  training,  the  decision  was  made  to  have  the 
SDS  operate  on  an  interactive  menu  driven  basis  with  on-line 
assistance  available.  Also,  the  databases  were  to  be 
maintained  and  supported  by  an  online  mass  storage  (disk) 
system,  with  enough  storage  capability  to  hold  the  databases 
and  still  have  enough  reserve  for  future  growth. 

The  initial  release  of  the  application  software  was 
an  attempt  at  going  for  the  "quick  victory"  to  gain  support 
of  the  user  communities,  w'hile  later  releases  were  to 
include  greater  depth  and  scope  in  the  applications 
provided.  The  first  release  of  SNAP  II  SDS  was  developed 
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concurrently  with  the  hardware  acquisition  so  that  it  would 
be  operationly  certified  by  the  time  of  the  first  hardware 
delivery.  [Ref.  52] 

One  early  problem  encountered  was  getting 
concurrence  on  the  functional  specifications  for  the  various 
SDS  subsystems.  This  was  primarily  due  to  different 
procedures  between  the  Atlantic  fleet  and  Pacific  fleet 
commands,  as  well  as  differences  between  ship  types  and 
sizes.  The  most  difficult  point  to  sell  was  that  SNAP  II  was 
not  just  an  automation  of  existing  procedures,  but  rather  a 
total  replacement  of  existing  procedures  with  an  integrated, 
automated  system.  In  the  end,  the  functional  sponsors  for 
each  of  the  subsystems  designated  the  procedural 
requirements  to  be  included  in  the  initial  release  of  SDS. 
In  all,  nine  distinct  subsystems  were  planned.  See  Table 
III  [Ref.  53]. 


TABLE  III 

SNAP  II  SDS  Subsystems 


1)  Systems  Management  6)  Pay/Disbursing 

2)  Corrective  Maintenance  7)  Personnel 

3)  Preventative  Maintenance  8)  Administration 

4)  Aviation  Maintenance  9)  Medical. 

5)  Supply  Financial 


I 


5.  SNAP  1 1  System  Acquisition  and'  Selection 

In  November  1981,  the  Naval  Sea  System  Command 
issued  a  contract:  to  Systems  Management  American  ( SMA)  Inc., 
"for  the  acquisition  and  logistical  support  of  the  ADP 
hardware,  software,  and  related  services  for  SNAP  II" 
[Ref.  54],  This  contract  was  expected  to  exceed  $200 
million  over  its  20  year  life-cycle.  It  was  issued  to  SMA 
as  a  Small  Business  Administration  "8(a)"  set-aside,  which 
is  part  of  a  Minority  Small  Business  and  Capital  Development 
program  to  "promote  equal  access  to  government  contracts" 
for  those  who  are  both  socially  and  economically 
disadvantaged  [Ref.  55].  SMA  Inc.,  is  owned  by  Herman  E. 
Valentine,  who  is  president  and  corporate  chairman.  In  1982 
SMA  was  ranked  nationally  as  the  32nd  largest,  "black  owned" 
company  in  the  United  States,  with  gross  revenue  of  about 
$17  million.  One  year  later,  sales  topped  $31  million,  with 
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national  ranking  to  17th.  [Ref.  56] 

The  Navy  contract  calls  for  SMA  to  act  as  the 
"system  integrator"  acquiring,  ruggedizing,  and  integrating 
the  computer  system  components.  The  acquisition  of  the 
system  components  was  to  be  throuc h  a  competitive  selection 
process  wholly  controlled  by  SMA.  The  use  of  an  integrating 
contractor  for  SNAP  II  had  the  advantage  of  reducing  the 
extensive  time  delays  and  complexities  of  a  major  system 
acquisition,  and  gave  the  Navy  a  single  contractor  to  deal 
with  in  resolving  all  hardware  and  system  software  problems. 

The  SNAP  II  selection  process  was  conducted  by  SMA 
in  November  1981,  with  seventeen  vendors  submitting 
proposals.  See  Table  IV  for  the  list  of  bidders.  [Ref.  57] 
The  selection  was  made  by  "SMA's  technical  and  managerial 
staff,  augmented  by  consultants  from  private  industry  and 
Old  Dominion  University"  [Ref.  58]. 
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TABLE  IV 

Vendors  Bidding  on  SNAP  II  Requirements 

Harris 
Honeywell 
IBM 
WANG 

Electronic  Marketing 
Hetra 
Mi ltope 

Wright  Marketing 


Bv  December  1981.  the  field  had  been  narrowed  to 
three  proposals  which  had  been  selected  for  further 
evaluation.  These  included  Data  General,  Harris,  and 
Honeywell.  All  other  proposals  evaluated  by  SMA  were  deemed 
unacceptable.  [Ref.  59] 

On  December  23,  1981  SMA  completed  the  evaluation 
process  and  announced  the  selection  of  the  proposal  bid  by 
the  Harris  Corporation.  The  Harris  300  computer  systems  had 
been  selected  for  SNAP  II  even  though  they  had  never  been 
used  in  any  major  business  system  applications. 

An  interesting  point  here  is  that  the  functional 
specifications  for  the  SNAP  II  system  called  for  it  to  be 
fully  compatible  with  SNAP  I  to  allow  the  transfer  data 
files  between  systems.  Only  a  few  months  after  SMA' s 
selection  of  the  Harris  computers  for  the  SNAP  II  system, 
Honeywell  DP-6  computer  systems  were  selected  for  SNAP  I 
systems . 


C3  (Convergent  Technologies) 
C3  (Perkin  Elmer) 

CPT  (Submarine  Only) 

Data  General 
Datapoint 
Digital  Equipment 
Federal  Data  (TI) 

G.  E.  Aerospace 
Memo rex 


In  January  1982,  the  performance  validation  testing 
was  conducted  on  the  proposed  Harris  system.  The  test 
results  showed  that  the  system  was  having  problems  with  the 
Performance  Validation  Instruction  Package  Software.  After  a 
second  revalidation  test  later  that  month  only  one 
discrepancy  remained,  which  dealt  with  the  interpretations 
of  "response"  and  "response  time"  [Ref.  60],  The  Harris 
system  finally  passed  the  benchmark  tests  in  early  February 
1982,  with  20  successful  runs  and  an  average  response  time 
of  less  than  3  seconds,  as  called  for  in  the  functional 
specifications.  From  their  evaluation  and  analysis  of  the 
work-load  requirements  and  data  available  from  NAVMASSO,  SMA 
recommended  memory  requirements  for  the  Harris  300  computers 
to  be  used  in  three  different  configurations: 

-  small  384Kb 

-  medium  768Kb 

-  large  1.5Mb 

Since  the  Harris  equipment  is  expandable  to  3.0Mb,  it 
appeared  to  meet  the  system  specification  requirements. 
[Ref.  61] 

In  March  1982,  the  Commanding  Officer  of  the 
Operational  Test  and  Evaluation  Force  ( COMOFTEVFOR ) 
expressed  concern  about  the  hardware  selected  by  SMA  for  the 
SNAP  II  system.  After  two  demonstrations  of  the  proposed 
hardware  systems,  it  was  clear  that  some  of  the 

specifications  identified  in  the  contractual  Statement  of 
Work  (SOW)  were  not  being  met.  The  specific  items  identified 
included  the  following  [Ref.  62], 

a.  The  system  had  an  inadequate  diagnostic  system  for 
system  maintenance. 

b.  The  Harris  300  minicomputer  had  never  been  proven  in 
a  major  business  application. 

c.  There  was  no  uninterruptable  power  source  to  assure 
power  during  outages. 
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d.  The  keyboard  video  display  terminals  were  not 
provided  with  editing  keys  for  text  editing,  or  with 
user  adjustable  brightness/glare  controls. 

e.  The  response  times  were  slower  than  called  for  in  the 
specifications . 

f.  The  system  provided  no  "fail  soft"  protection  for  the 
subsystem  levels  of  operation 

g.  There  was  no  word  processing  capability. 

h.  The  printers  were  all  from  different  manufacturers, 
meaning  that  there  was  no  printer  family 
inter-operability  and  that  there  would  be  increased 
logistic  requirements  for  repair  parts. 

While  none  of  the  deficiencies  cited  by  COMOPTEVFOR  were  in 
themselves  insurmountable,  they  pointed  out  a  basic  problem; 
the  hardware  specifications  defined  in  the  Statement  of 
Work,  USN  Solicitation  N00024-81-R-7165 ,  were  not  being 
fully  complied  with  by  SMA. 

The  Harris  300  series  minicomputer  had  been  modified 
to  meet  sis. i  requirements  of  the  design  specifications.  This 
required  changing  the  circuit  boards  from  their  origins 
vertical  configuration,  to  a  horizontal  position  and 
reducing  the  ventilation  space  above  the  computer  circuit 
cards.  A  direct  result  of  this  was:  1)  the  natural 
ventilation  past  the  circuit  cards  was  lost,  2)  the  circuit 
boards  warped  in  the  horizontal  position  causing  them  to 
make  poor  contact  with  their  connectors,  and  3)  they 
presented  an  excellent  surface  for  the  accumulation  of  dust 
from  unfiltered  air,  further  reducing  heat  transfer  from  the 
boards , 

After  extensive  testing  and  evaluation,  the  first 
SNAP  II  system  was  installed  on  U.S.S  SIDES  (FFG-14)  in 
January  1983. 


78 


an 


' 6 •  Operational  Test  and  Evaluation  of  SNAP  1 1 

During  the  period  of  March  7-18,  1983, 

operational  assessment  of  SNAP  II  was  conducted  on  board 
U.S.S.  SIDES.  COMOPTEVFOR  described  the  system  as 
potentially  operationally  effective,  but  not  operationally 
suitable  for  shipboard  use,  and  recommended  that  it  not  be 
approved  for  fleet  introduction.  [Ref.  63]  During  the  test, 
designated  OT-IIA,  the  SNAP  II  system  was  thoroughly 
evaluated  according  to  the  performance  standards  provided  in 
the  systems  test  plan.  The  results  of  OT-IIA  pointed  out 
several  problems  with  the  SNAP  II  system  provided  by  SMA. 
[Ref.  64] 

a.  The  response  time  was  slower  than  the  design 
specifications . 

b.  Any  user  could  use  job  control  language  to  change  the 
ownership  and  attributes  of  the  files  in  the  central 
database,  without  setting  off  an  alarm  or  leaving  an 
audit  trail  to  indicate  actual  or  attempted  entry 
into  the  restricted  files.  While  the  SNAP  II  system's 
data  files  are  unclassified,  the  database  does 
contain  information  covered  by  Privacy  Act 
regulations  as  well  as  financial  accountability  data 
for  disbursing,  ships'  store,  food  service,  and 
supply  management. 

c.  The  size  and  weight  of  the  system  installed  on  board 
U.S.S  SIDES  was  far  beyond  the  design  specifications 
provided  in  the  functional  description.  They  called 
for  a  system  which  would  be  no  larger  than  26  inches 
wide  by  60  inches  tall  (so  it  would  fit  through  a 
standard  hatch)  and  weigh  nc  more  than  130  pounds. 
The  SNAP  II  system  weighed  an  unbelievable  2257 
pounds  and  was  mounted  in  a  dual  cabinet  that  was  26 
inches  by  70  inches  by  48  inches,  thus  presenting  a 
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significant  problem  for  installing  these  systems  on 
submarines  and  smaller  ships  in  the  fleet. 

d.  Unfiltered  air  was  being  drawn  through  the  computer 
cabinets  and  keyboard  video  display  terminals  (KVDT), 
causing  dirt  accumulation  on  the  circuit  boards  and 
internal  components. 

e.  The  magnetic  tapes  and  floppy  disks  produced  on  the 
SNAP  I  system  could  not  be  loaded  into  the  Harris 
system.  This  data  transfer  was  required  for  passing 
maintenance  related  job  orders  from  the  Current 
Ship's  Maintenance  Project  (CSMP),  as  well  as  other 
supply  related  data. 

f.  The  system  operator/coordinator  considered  the  SNAP 
II  system  too  slow,  and  not  user  friendly.  This 
situation  could  only  get  worse  as  more  application 
programs  are  added  to  SNAP  II.  Also,  there  was 
insufficient  space  for  the  users  at  the  work  stations 
and  around  the  computer  itself. 

g.  The  concept  cf  providing  system  coordinators  and 

maintenance  personnel  with  only  two  weeks  of  training 
on  the  SNAP  II  system  did  not  appear  to  provide  them 
with  a  sufficient  knowledge  of  the  system  and  its 
capabilities.  The  U3ers  and  system  managers  were 
unaware  of  a  several  functions  and  procedures 

available  on  the  system. 

h.  The  non-standard  keyboards  provided  with  the  system 

were  difficult  to  use,  even  for  an  experienced 

typist . 

These  issues,  as  well  others,  lead  to  the 
recommendation  by  CQMOPTEVFGR  that  the  Navy  not  procure  any 
additional  SNAP  II  systems  until  they  have  successfully 
passed  an  operational  test  and  evaluation  examination  to 

ensure  the  system  meets  requirements.  [Ref.  65] 
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Only  two  weeks  before  OT-IIA,  the  Naval  Sea  Combat 
Systems  Engineering  Station  had  conducted  a  First  Article 
Test  Afloat  of  the  SNAP  II  system  installed  on  the  U.S.S. 
SIDES.  This  test  was  to  verify  the  installation  procedures, 
to  establish  a  base  line  production  configuration,  and  to 
verify  many  of  the  same  functional  requirements  later 
inspected  during  OT-IIA.  On  March  1,  1982  they  reported  a 

successful  First  Article  Test  and  recommended  system 
procurement  and  implementation  [Ref.  66).  Based  on  that 
recommendation,  in  May  1983,  approval  was  granted  for  the 
procurement  and  installation  of  the  first  40  SNAP  II 
systems.  Acquisition  authority  for  the  procurement  of 
additional  SNAP  II  systems  was  contingent  on  the  successful 
completion  of  a  second  Operational  Test  and  Evaluation, 
designated  OT-IIB. 

The  second  operational  test  and  evaluation  for  SNAP 
II  (OT-IIB)  was  conducted  on  board  the  U.S.S.  cfthKioN 
( FFG-22 )  from  October  17  to  November  2,  1983,  while  the  ship 
transited  form  Mayport,  Florida  to  Rota,  Spain.  Once  again, 
OPTEVFOR  concluded  that  rhe  SNAP  II  system  was  not 
operationally  suitable  for  use  in  the  fleet.  This  finding 
was  based  on  the  validation  criteria  provided  in  the  SNAP  II 
Test  and  Evaluation  Master  Plan  657  (CH-2)  of  August  8, 

19S3 .  During  the  evaluation  they  noted  that  only  12  of  the 
20  system  discrepancies  from  the  first  test  (OT-IIA)  had 
been  corrected.  The  SNAP  II  system  problems  noted  during 
this  evaluation  included  [Ref,  67],  : 

a.  The  response  time  still  exceeded  the  three  seconds 
maximum  requirement  of  the  contract  specifications 
often  taking  30  seconds  or  longer  to  respond. 

b.  The  power  backup  system  was  not  adequate,  requiring 
the  system  operators  to  reboot  the  system  after  each 
power  loss  and  reset  the  real-time  clock. 
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c.  80%  of  the  database  applications  could  not  view  the 
data  at  the  video  display  terminals,  but  could  only 
provide  hard  copy  printouts. 

d.  The  system  ran  without  an.  operator  75%  of  the  time 
(criteria:  90%) . 

e.  SNAP  II  was  still  overweight  and  oversized,  though  a 
600  pound  power  supply  had  been  removed  from  the 
system  and  the  total  system  weight  was  reduced  to 
1496  pound3.  (OT-IIA  system  weight  was  2257  pounds) 

f.  The  mean  time  between  failures  was  16.6  hours  (OT-IIA 
was  43.1)  while  the  criteria  was  established  at  2000 
hours  between  failures. 

g.  The  external  interface  with  the  Radio  Central  message 
center  did  not  work  when  paper  tape  message  data  was 
fed  into  SNAP  II, 

h.  The  security  system  still  gave  a  user  with  access  to 
the  job  control  language  the  ability  to  change  the 
ownership  and  or  characteristics  of  a  file  without 
setting  off  an  alarm  or  leaving  an  audit  trail. 

i.  It  was  taking  the  maintenance  personnel  an  average  of 
three  hours  to  find  and  repair  casualties,  based  on 
eighteen  trials  (criteria:  45  minutes). 

j.  The  printers  jammed  as  the  ship  rolled  underway. 

k.  Dirt  still  accumulation  on  internal  circuit  boards  of 
the  computer  and  KVDTs  because  of  unfiltered  air 
drawn  through  the  systems. 

l.  There  was  no  room  to  lay  documents  near  terminals 
while  typing,  and  the  MUSE  IV  word  processor  could 
not  provide  OCR  documents. 

m.  'hanging  circuit  boards  was  extremely  difficult 
because  of  the  small  amount  cf  vertical  clearance 
between  circuit  cards  and  most  of  interconnecting 
cables  at  the  front  of  the  cards. 
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The  vision  of  an  easy  to  operate/maintain,  user 
friendly,  highly  reliable  system  was  quickly  fading.  Many  of 
the  functions  provided  by  the  system  were  not  used  because 
of  lack  of  on  board  expertise.  Also,  only  a  few  applications 
were  being  programmed  by  on  board  users  in  BASIC  or  AZ-7 
query/report  generator  languages. 

The  failure  of  the  SNAP  II  system  to  pass  the  test 
and  evaluation,  OT-IIB,  prompted  Vice  Admiral  Baciocco 
(QP-098)  to  express  his  concern,  and  desire  for  a  third 
operational  test  later  designated  OT-IIC.  It  was  clear  at 
this  point  that  not  all  the  functional  design  specifications 
provided  in  the  contract  with  SMA  could  be  met  by  the  Harris 
Computer  System.  Also,  the  software  provided  by  NAVMASSO 
would  need  a  great  deal  more  work,  if  all  the  application 
programs  cited  in  the  integrated  functional  description  were 
going  to  be  provided. 

In  December  1983,  the  Commander  of  the  Naval  Surface 
Forces  Atlantic  ( COMNAVSURFLANT )  consolidated  comments  from 
the  thirteen  ships  of  the  Atlantic  Fleet  that  had  SNAP  II 
systems  installed.  The  command  comments  indicated  an 
overwhelmingly  positive  response  to  the  SNAP  II  system, 
Wnile  problems  still  existed  with  SNAP  II,  the  users  found 
it.  a  significant  improvement  over  manual  processing. 

"Ail  have  praised  overall  system  operc  and 
effectiveness  in  achieving  the  program  goal  o*  /educed 
admin  ef fort ...  SNAP  II  has  dramatically  eased  c  ^  burden 
on  a  minimally  manned  ship... Is  unaauivocal ly 
recommended  for  fleet  introduction.  [Ref.  68]. 

It  seems  a  paradox  for:  the  system  to  be  declared  unsuitable 
for  shipboard  use  and  yet  receive  such  strong  endorsement 
from  the  shipboard  users.  The  answer  lies  in  the  change  from 
manual  procedures  to  automated  processing.  While  the 
statement  of  work  (SOW)  defined  specific  processing 
requirements,  the  users  were  just  happy  to  have  the  SNAP 
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system  on  board,  even  if  many  of  the  functional  subsystems 
of  SNAP  II  were  not  working  up  to  the  technical  design 
standards.  The  SNAP  II  system  was  providing  the  ships' 
Commanding  Officers  the  tools  needed  to  solve  shipboard 
management  problems. 

In  March  1984,  after  a  great  deal  of  discussion,  the 
Vice  Chief  of  Naval  Operations  directed  that  the  Master  Test 
Plan  for  OT-IIC  be  modified  to  include  only  those  "system 
requirements  and  characteristics  required  for  fleet 
introduction. "  {Ref.  69]  Only  45  of  the  210,  specific 
requirements,  from  the  integrated  functional  description, 
were  included  in  the  revised  test  plan  for  OT-IIC.  Many  of 
the  specific  performance  requirements  had  been  eased.  (  For 
example,  the  response  time  requirement  was  increased  from, 
less  than  three  seconds,  to  not  less  than  6  to  30  seconds 
depending  on  the  situation.  Also,  the  mean  time  for 
repairing  the  system  during  hardware  failures  was  increased 
from  45  to  90  minutes. 

The  third  Operational  Test  and  Evaluation  was 
conducted  in  early  May  1984  on  board  the  U.S.S.  Arthur  W. 
RADFORD  (DD-968).  Of  the  20  deficiencies  from  the  previous 
test,  10  were  still  unresolved  and  of  the  44  application 
software  problems,  only  four  were  rein3pected.  The  response 
times  were  still  slow  with  an  average  of  7.7  to  11.5  seconds 
with  various  system  loads,  and  a  41. S  seconds  average  time 
to  sign-on  the  system.  Most  of  those  discrepancies  from  the 
previous  evaluation  OT-IIB  remained,  except  for  system 
security,  which  had  been  improved  with  software  traps  to 
prevent  unauthorized  or  inadvertent  access  to  system  files. 
The  system's  maintenance  men  easily  passed  the  new  standard 
of  90  minutes  for  making  system  repairs. 

Based  on  the  findings  of  OT-IIC,  COMOPTEVFOR,  stated 
"If  satisfying  the  requirements  set  forth  in  the  revised 
Master  Test  Plan  are  adequate  for  supporting  full 
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production,  then  operational  ef f ectiveness  and  operational 
suitability  support  recommendation  for  full  production  of 
SNAP  II."  [Ref.  70] 

The  Deputy,  Under  Secretary  of  the  Navy  for 
Financial  Management  granted  approval  for  full  production  of 
the  SNAP  II  systems  in  June  1984,  based  on  the  findings  and 
recommendations  of  COMOPTEVFOR  from  the  third  evaluation, 
OT-IIC.  As  of  September  1984,  56  SNAP  II  systems  had  been 
installed  on  surface  ships.  The  rate  of  installation  was 
scheduled  to  be  eight  SNAP  II  systems  per  month  until  all 
452  ships  :  completed.  One  problem  being  encountered  by 
the  fleet  ^  mmanders  has  been  matching  ships'  operational 
schedules  to  the  dates  available  for  installation.  This 
problem  has  been  compounded  by  the  lack  of  authorized  Ship 
Alterations  (SHIPALTS),  which  must  be  completed  ar.d 
authorized  before  installation  of  the  SNAP  II  hardware.  As 
of  December  1984,  only  five  of  38  SHIPALTS  had  oeen 
completed,  representing  145  ships.  [Ref.  71] 


C.  ESSENCE  OF  SNAP  II 

The  SNAP  II  program  was  the  second  part  of  of  a  two 
phase  program  for  modernizing  and  expanding  the  automated 
data  processing  capability  in  the  U.S.  Navy.  SNAP  I  was  to 
replace  the  AN/UYK-5(V)  computer  systems  installed  on  the 
larger  ships  of  the  fleet  since  the  mid-60s,  while  SNAP  II 
was  to  provide  an  ADP  capability  to  the  smaller  ships  which 
were  primarily  non-automated.  With  the  advent  of  large 
scale  integration  of  computer  components  with  their 
increased  reliability  and  declining  cost,  it  was  now 
economically  feasible  to  provide  non-tactical  computer 
systems  to  every  command  in  the  fleet. 
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The  philosophy  of  the  SNAP  program  was  to  provide  every 
surface  ship  and  submarine  in  the  fleet  with  an  automated 
data  processing  capability  to  support  shipboard  management 
and  reduce  the  manual  work  load  requirements  on  the  crew 
used  in  processing  data  and  directing  shipboard  activities. 
By  centrally  procuring  the  system  hardware  and  software, 
logistic  problems,  training  requirements,  and  overall 
life-cycle  costs  would  be  minimized.  Each  ship  or  submarine 
would  have  one  of  four  authorized  hardware  configurations 
depending  on  ship  class  and  type.  These  initial 
configurations  give  each  command  a  base-line  capability 
which  can  be  expanded  later. 

The  primary  gains  from  SNAF  II,  as  reported  by  Pacific 
fleet  commands  include:  1)  better  use  of  assigned  manpower, 
2)  increased  accuracy  of  data  sent  to  shore  support 
activities,  3)  improved  ships  configuration  management,  and 
4)  efficient  aduuini strati ve  support  [Ref.  72} 

The  SNAP  II  is  made  up  of  thre*.  primary  systems  joined 
together  under  the  control  of  a  Harris  minicomputer.  These 
include  the  hardware,  the  system  software,  and  the 
application  software.  The  hardware  and  system  software  are 
provided  under  contract  with  Systems  Management  American 
(SMA)  Inc.,  while  the  application  software  is  developed, 
designed,  and  installed  by  NAVMASSO  in  Norfolk,  Virginia. 
NAVMASSO  is  also  the  c jntral  design  activity  for  the  SNAP  II 
system.  The  application  software  is  primarily  written  in 
COBOL,  using  a  hierarchical  modular  design  to  improve  its 
maintainablity  and  to  support  the  introduction  of  later 
software  releases  and  additional  application  program 
modules . 

The  systems  have  on-line  user  manuals,  documentation, 
and  diagnostic:  systems  providing  the  users  and  system 
operators  with  easily  understood  English-like  information. 
This  is  necessary  because  SNAP  II  systems  are  designed  to  be 
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installed  on  ships  that  do  not  have  ADP  experts  specifically 
assigned  for  running  or  maintaining  the  systems.  Instead, 
each  ship  sends  crew  members  to  system  coordinator  and 
system  maintenance  schools,  which  are  about  two  weeks  in 
length.  The  individuals  in  turn  provide  the  training  for  the 
rest  of  the  users  and  functional  area  supervisors. 

The  schedule  for  SNAP  II  installations  runs  through  1989 
and  includes  472  sites,  both  afloat  and  ashore.  The  planned 
delivery  schedule  requires  the  installation  of  about  eight 
systems  per  month  during  that  five  year  period,  and  presents 
a  scheduling  nightmare  matching  available  ships  with 
installation  teams,  and  authorized  SHIPALTs.  See  figure 
4.1  [Ref.  73]. 

Based  on  the  modified  requirements  from  the  OT-IIC  test 
plan,  SNAP  II  is  now  considered  to  provide: 

1.  response  times  from  6  to  30  seconds 

2.  mean  time  for  component  failure  ot  2000  hours 

3.  less  than  five  reboots  per  day 

4.  mean  time  for  repairing  casualties  of  9C  minutes 

5.  85%  system  availability 

6.  unattended  operations  65%  of  the  time 

The  SNAP  II  system  is  limited  to  unclassified  data  and 
programs  because  of  the  stringent  security  requirements 
required  to  store  and  process  classified  data  on  a  shared 
computer  system.  This  limitation  seriously  restricts  the 
amount  of  operational  planning  and  reporting  that  can  be 
done  on  SNAP  II.  A  possible  solution  would  be  to  use 
stand-alone  Zenith  150  series  microcomputers  with  10  Mb  hard 
disk3  which  are  TEMPEST  certified  for  processing  classified 
data,  but  no  hard  copy  would  be  possible  unless  the  printer 
was  also  TEMPEST  certified. 

At  the  time  of  this  writing,  the  Zenith  120/150 
microcomputers  were  well  on  their  way  to  becoming  a  fleet 
standard.  Because  of  delays  in  the  development  of  some 
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Figure  4.1  SNAP  Installation  Schedule 

software  applications  for  SNAP  II,  several  application 
programs  have  been  produced  for  the  Zenith  systems  including 
retail  operations,  food  service  operations,  and  disbursing. 
These  applications  do  not  interface  other  parts  of  the  SNAP 
II  database  and  are  thus  appropriate  for  the  stand-alone, 
systems,  especially  since  these  are  all.  areas  of  financial 
accountability.  [Ref.  74]  These  application  programs  are 
not  scheduled  for  implementation  on  SNAP  II  until  after 
fiscal  year  1986. 
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There  has  been  much  discussion  about  providing  better 
system  response  time  and  up-grading  the  hardware  for  the 
SNAP  II  system.  These  areas  are  discussed  in  later  sections 
of  this  chapter.  Other  future  plans  include  using 
microcomputers  to  access  the  Harris  computer,  instead  of  the 
KVDTs  now  used.  This  would  permit  some  of  the  processing 
functions  to  be  off-loaded  as  well  as  providing  the 
capability  of  running  commercial  software  packages  on  the 
SNAP  system. 

So  far  SNAP  II  has  been  well  received  in  the  fleet,  with 
most  commands  concluding  that  the  "economic  benefits  of  the 
centralized  system  outweigh  its  limitations"  [Ref.  75]. 
Other  comments  though  indicate:  1)  there  is  a  general 
feeling  that  there  are  not  enough  KVDTs  (at  least  two  more 
needed),  2)  there  are  some  problems  with  circuit  cards 
vibrating  loose  during  underway  operations,  and  3)  there  is 
the  need  to  power  the  SKA?  II  system  with  a  "vital"  power 
source,  so  it  doesn't  have  to  be  shut  down  every  time 
non-vital  power  sources  ate  lost. 

1.  SNAP  I_I  Hardware 

The  Automated  Data  Processing  Equipment  (ADPE)  for 
the  SNAP  II  system  is  designated  AN/UYK-62 ( v) .  It  is 
provided  by  Systems  Management  American  (SMA)  Inc.,  undsr  a 
Navy  contract  which  requires  them  to  purchase,  integrate, 
and  ruggedi.se  the  system  components.  The  components  are 
arranged  in  one  of  four  configurations,  large,  medium, 
small,  and  small  (submarine).  See  Table  V  [Ref.  76]-  Each 
conf i gux ation  is  nearly  identical,  except  for  the  number  of 
peripheral  units  attached. 

a.  Processor  Subsystem 

The  Harris  300  super-mini  computer  is  the  heart 
of  the  the  SNAP  II  system.  Ith  uses  a  48  bit  word-size,  plus 
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the  address  and  control  bits.  Internal  data  is  transmitted 
in  parallel  at  a  speed  of  19.2Mb  per  second.  The  main 
memory  is  expandable  to  3.0Mb,  though  the  current  SNAP  II 
configuration  uses  only  1.5Mb  of  random  access  memory  (RAM). 
With  the  addition  of  a  70  nano- second  cache  memory  and  the 
expanded  memory,  the  system  can  be  converted  into  a  Harris 
500  computer,  with  operating  characteristics  similar  to  an 
IBM  370/158  computer.  [Ref.  77] 

The  commercial  version  of  the  Harris  computer 
mounts  in  an  equipment  rack  that  is  80"high  by  44"wide  by 
32 "deep  and  weighs  1050  pounds.  The  contract  specifications 
for  the  SNAP  II  system  called  for  SMA  to  provide  a  computer 
system  that  was  proven  in  business  applications,  no  larger 
than  26  inches  wiae  by  60  inches  tall  (so  that  it  could  fit 
through  a  standard  shipboard  hatch),  and  about  130  pounds  in 
weight  (to  meet  small  ship  weight  limitations).  [Ref.  78] 
The  SNAP  II  model  of  the  Harris  computer  required 
significant  modification  of  the  "off-the-shelf"  version, 
since  it  did  not  meet  any  of  these  criteria.  At  present  the 
Navy's  SNAP  II  system  is  the  beta  test  site  for 
modifications  and  changes  to  the  Harris  system  hardware  and 
software . 

Additionally,  the  central  processing  unit  (CPU) 
of  the  processor  subsystem  includes  the  communication 
network  processors,  a  power  distribution  system,  and  the 
programmers  control  panel. 
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SNAP  II  Shipboard  Configurations 

Eau  i  pinont  La  roa  Mad  i  urn  Sma  I  I  Sna  I  I ( sub ) 

Ha  inf rame 

Harris  300  Main  Memory  1 . 5  Mb  1.5  Mb  1.5  Mb  1 . 5  Mb 

Virtual  Memory  12  Mb  12  Mb  12  Mb  12  Mb 

Winchester  80Mb  Hard  Disk  4322 

Nina  Track  Mag  Tape  Drive  1111 

Papar  Tape  Reader/Punch  1111 

Terminals 

User  Terminals  16  8  4  I 

Operator  Terminals  1111 

Printers 

300  IPS  Lino  Printers 
Display  Printers 
Word  Processing  Printers 


2  2  1 

1  1  0 


Othe  r 

8"  Floppy  Disk  Drives  2 

Card  Reader  1 


2  2  11 

8  2  2  1 

4  2  2  0 


b.  Input/Output  Subsystem 

The  I/O  Subsystem  provides  the  primary  interface 
with  the  SNAP  II  users.  It  includes  display  terminals, 
printers,  and  other  I/O  devices. 

The  systems  include  KVDTs  which  have  an  80 
column,  24  line  display,  and  are  capable  of  handling 
graphics. 

There  are  three  kinds  of  printers  provided  with 
SNAP  II,  including:  1)  display  printers  for  making  hard 
copies  of  KVDT  screen  displays,  2)  line  printers,  which  run 
at  300  lines  per  minute  for  volume  printing  jobs  using 
continuous  forms  (5"  to  16"  wide)  and  3)  work  processor 
printers  for  letter  quality  printing,  capable  of  using  a 
variety  of  different  fonts. 

Other  I/O  devices  include  a  paper  tape 
punch/reader  for  the  interface  with  the  ships'  communication 
center  and  a  card  reader  for  inputing  supply  requisition 
status  cards  provided  by  shore  commands.  (The  tape  and  disk 
drives  are  listed  with  the  storage  devices.) 

c.  Mass  Storage  Subsystem 

This  subsystem  includes  the  devices  used  to 
store  the  data  and  software  programs  for  the  SNAP  II  system. 
Since  the  SNAP  II  system  is  designed  to  run  without  an 
operator,  most  of  the  storage  is  on  hard  disks.  The  various 
configurations  provide  for  two  to  four  Winchester  sealed 
hard  disk  drives,  with  four  8  inch  disks  and  seven 
read/write  heads.  For  system  back-up  there  are  9- track 
magnetic  tape  drives,  which  run  at  an  average  speed  of  75 
inches  per  second  with  a  density  of  1600  bits  per  inch. 
Finally,  there  are  8  inch  floppy  disk  drives  which  are  used 
to  receive  or  provide  data  with  external  sources,  i.e.  SNAP 
I  systems. 
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d.  Power  Subsystem 


The  power  subsystem  is  provided  to  ensure  an 
orderly  shut-down  of  the  SNAP  II  system  when  there  is  a 
power  failure.  It  includes  four  types  of  electrical 
line-filter  used  to  regulate  the  line  voltage  to  the  SNAP 
II  system. 

e.  Future  Hardware  Plans 

The  future  plans  for  ADPE  improvement  look 
promising,  and  should  solve  many  of  the  early  problems  with 
reliability,  speed  and  system  size.  These  plans  include 

1.  expanding  the  Harris  main  memory  and  increasing  the 
size  of  the  virtual  memory  addressed  by  the  operating 
system 

2.  using  denser  hard  disks  to  provide  160Mb  per  disk 
pack 

'l  vflHnrinrf  V\r>-fr-Vi  ei  7o  i  rtV»  +-  r\  f  thp  r'nmnnn^nt’S 

w.  —  -  —  - -  - -  -  - r  - - w 

and  the  equipment  rack 

4.  increasing  the  number  of  terminals 

5.  using  portable  microcomputers  in  place  of  terminals, 
fitted  with  hard  disks  and  up  to  600K  of  RAM,  to 
allow  off-loading  of  some  applications 

A  current  listing  of  SNAP  II  equipment  manufacturers  and 
vendors  is  provided  in  Appendix  A. 

2 .  SNAP  I I  System  Software 

SMA  provides  the  system  software  for  the  SNAP  II 
system.  The  system  software  includes  the  operating  system, 
utility  software,  and  compilers.  The  Harris  300 

minicomputer  uses  the  Vulcan  Operating  System  (VOS),  which 
is  capable  of  addressing  12Mb  of  virtual  memory.  VOS 
supports  nine  high  level  languages,  including:  1)  COBOL,  2) 
FORTRAN  77,  3)  Pascal,  4)  TOTAL  DBMS,  5)  AZ--7  query 
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language/report  generator,  6)  T-ASK  information  retrieval 
system,  7)  APC,  8)  SORT/MERGE,  and  9)  MUSE  IV  word 
processing  language.  Not  all  these  languages  are  provided  to 
the  ships  with  the  SNAP  II  systems.  The  shipboard  version 
of  SNAP  II  only  comes  with  AZ-7,  SORT/MERGE,  MUSE  IV,  and  a 
BASIC  language  compiler.  Since  the  application  software 
provided  with  the  system  is  written  in  COBOL,  shipboard 
users  are  not  allowed  to  use  COBOL.  This  is  done  to  protect 
the  programs  and  database  provided  with  the  system. 
[Ref.  79] 

Since  the  selection  of  the  Harris  computer  for  the 
SNAP  II  system,  there  have  been  problems  with  the  operating 
system.  The  primary  complaint  has  been  that, 

"the  current  SNAP  II  system  suffers  from  inefficiency  in 
both  run-time  throughput  and  response  time.  Specifically 
shipboard  users  have  voiced  concerns  regarding  the 
excessive  amount  of  time  required  to  perform  routine 
functions  while  utilizing  SNAP  II.  [Ref.  80] 

The  main  difficulty  lies  with  the  operating  system  itself. 
VOS  supports  an  indexed  sequential  file  management  system 
called  VISP,  which  does  not  allow  file  sharing.  With  several 
users  trying  to  access  the  same  files,  the  system  soon  slows 
to  a  crawl.  Other  problems  cited  in  one  report  provide  an 
insight  into  some  of  the  VOS  problems.  [Ref.  81] 

a.  Alternate  indexed  files  are  not  efficiently  processed 
during  read  and  write  operations. 

b.  There  is  no  multiple  character  suppression  in  the 
indexed  files,  so  large  blocks  of  data  must  be  moved 
between  the  record  buffer  in  the  server  and  the 
pseudo  buffer  in  the  application  programs.  This 
requires  the  operating  system  to  allocate  large 
blocks  of  dynamic  memory,  causing  a  significant 
degradation  in  the  system  response  time. 
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c.  The  lack  of  multiple  character  (blank)  suppression, 
also  causes  large  amounts  of  disk  space  to  be  wasted. 

d.  Because  alternate-key  data  retrieval  slows  the  system 
down  so  much,  programs  have  been  developed  which 
artificially  eliminate  the  use  of  the  duplicate  keys. 
This  inturn  increases  the  record  size  and  complexity 
of  the  programs . 

e.  The  multi-user  version  of  VI SP  seems  only  to  be  an 
kludge  of  the  basic  system. 

In  July  1904  SWA  announced,  a  new  release  of  the 
operating  system,  VOS  3.1.1,  to  address  many  of  the  issues 
discussed  above.  In  particular,  the  new  release  would 
provide  a  new  multi-user  VISP  package  and  multi -character 
blank  suppression.  That  announcement  led  to  the  suspension 
of  almost  all  new  application  software  development  for  SNAP 
II,  while  the  new  operating  system  was  being  integrated. 
[Ref,  82]  This  caused  a  delay  in  software  development  of 
nearly  eight  months,  until  about  February  1985.  The  new 
version  of  VOS  improves  the  response  time  and  performance  of 
the  SNAP  II  system. 

3 •  SNAP  I I  Applic avion  Software 

Tiie  application  software  for  SNAP  II  .is  designed, 
developed,  and  maintained  by  NAVMASSO.  It  has  a  modular 
design  so  that  additional  software  releases  and  new 
application  software  modules  can  be  easily  added  to  the 
system.  This  significantly  reduces  the  cost  of  software 
maintenance.  The  SNAF  II  Shipboard  Data  System  (3DS) 
implementation  has  been  broken  up  in  two  distinct  phases. 
The  initial  release  was  designed  as  a  first  effort  at 
reducing  the  administrative  work- load  on  the  ships,  while 
the  follow-on  releases  are  phased  enhancements  of  the  basic 
system  or  new  functional  applications  defined  by  the  system 
sponsors . 
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SDS  has  four  functional  components  in  its  design:  1) 
The  System  Management  Subsystem  (SMS)  directs  the  overall 
operation  of  the  application  software  for  the  SNAP  II 
system.  2)  The  Organizational  Maintenance  Management 
Subsystem  (OMMS)  handles  all  administrative  aspects  of  the 
shipboard  maintenance  program.  3)  Supply  and  Financial 
Subsystem  (SFM)  manages  the  administrative  functions  of 
shipboard  supply  and  inventory  management.  4)  The 
Administrative  Data  Management  Subsystem  ^DM)  used  in 
supporting  shipboard  personnel  and  administrative  functions. 
Additionally,  SDS  accesses  the  word  processing  system 
software  which  has  been  described  by  the  users  as  "easy  to 
use  "  and  a  "real  time  saver".  Figure  4.2  [Ref.  S3].  shows 
the  relationships  of  the  primary  four  subsystems. 

a.  System  Manager  Subsystem 

The  SMS  is  the  control  module  for  the  shipboard 
data  system.  It  includes  functions  dealing  with  overall 
system  management,  system  integrity,  menu  selection,  on-line 
user  manual,  and  queuing  of  reports.  It  is  this  menu-driven 
module  that  the  users  must  first  deal  with  when  logging  on 
the  SNAP  system.  It  not  only  provides  system  security,  but 
also  has  the  back-up  and  recovery  modules  required  to  ensure 
the  integrity  of  the  databases.  A  diagram  of  the  major 
functions  of  SMS  is  displayed  in  figure  4.3  [Ref.  84]. 

b.  Supply  and  Financial  Management  Subsystem 

The  SFM  subsystem  provides  the  basic  tools  to 
eliminate  much  of  the  manual  supply  record  keeping  and 
reporting  functions,  as  well  as  providing  an  extensive 
inventory  management  capability.  As  the  systems  are 
currently  implemented,  when  maintenance  data  is  entered  the 
status  of  on  board  repair  parts  is  provide  to  the  user  by 
SFM,  If  the  parts  are  carried  on  board,  documents  are 
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consumption  expense  accounting  records,  needed  for  internal 
and  external  reports.  Figure  4.4  shows  the  major  functions 
provided  by  the  SFM  subsystem  [Ref.  85]. 

When  parts,  consumeables ,  or  services  are 
purchased  through  the  SFM  system,  the  MILSTRIP  data  used  in 
ordering  them,  is  queued  and  later  punched  in  message  format 
on  paper  tape  for  radio  transmission  through  the  ship's 
communication  center.  This  feature  has  saved  countless 
man-hours  and  has  significantly  increased  the  accuracy  of 
the  MILSTRIP  messages.  SFM  also  provides  access  to  the 
ship's  Consolidated  Ships  Allowance  Listing  (COSAL)  which 
includes  lists  of  the  repair  parts  and  components  for  the 
equipment  installed  on  board  a  specific  ship.  The  automated 
COSAL  is  arranged  by  Allowance  Part  Lists  (APL),  which 
reflect  the  repair  parts  that  a  ship  is  supposed  to  carry  on 
board  to  support  repairs.  One  weakness  of  the  SNAP  II 
system,  cited  by  many  of  the  users,  is  its  failure  to 
provide  an  automated  interface  with  shore  commands  that 
provide  the  APLs  and  the  COSALs  that  go  into  the  ship's 
COSAL  database.  In  general,  the  COSAL  data  have  not  been 
accurate  when  first  installed  with  SNAP  II  systems,  and  the 
updates  and  modifications  have  to  be  entered  by  hand,  one 
part  at  a  time  using  the  KVDTs.  This  can  be  an  incredibly 
slow  process  for  an  APL  that  lists  a  thousand  repair  parts. 
This  interface  problem  has  been  addressed  and  will  be 
resolved  by  1986  when  APL  data  will  be  provided  to  the  ships 
on  magnetic  media.  [Ref.  86].  There  is  a  certain  amount  of 
duplication  in  maintaining  the  COSAL  data  in  the  on-line 
database,  because  separate  paper  copy  must  also  be 
maintained,  for  periods  of  time  when  the  SNAP  II  system  is 
not  operational.  The  functional  modules  of  SFM  are  displayed 
in  figure  4.4  [Ref.  37]. 
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than  50  man-hours  can  be  saved  for  each  repair  availablity. 
OMMS  supports  on-line  entry  and  display  of  maintenance 
actions,  as  well  as  management  reports  and  scheduling  aids. 
It  provides  for  work-package  processing,  work-load  planning, 
and  on-line  ordering  of  repair  parts.  The  functional  modules 
included  in  OMMS  are  presented  in  figure  4.5  [Ref.  88]. 


d.  Administrative  Data  Management  Subsystem 

The  ADM  subsystem  will  eventually  contain  all 
aspects  of  personnel  management  and  administration  (except 
classified  information  management).  The  initial  release  of 
ADM  included  functions  for  monitoring  personnel  assignments, 
training,  and  career  development.  In  addition  the  database 
supported  by  ADM  is  used  to  track  health  &  morale  programs 
and  retention  programs.  The  primary  complaint  from  the  ADM 
users  has  been  the  time  required  to  maintain  the  files  for 
ADM.  The  functions  provided  by  the  initial  release  of  ADM 
are  presented  in  figure  4.6  [Ref.  89]. 

e.  Future  Application  Software  for  SNAP  II 

Over  the  next  three  years,  there  will  be 
additional  application  software  modules  added  to  the 
shipboard  data  system,  as  well  as  improved  or  modified 
releases  of  the  existing  programs.  The  present  plan  calls 
for  the  following  application  programs  to  be  added  to  the 
system  (Ref.  90]  : 

Organizational  Maintenance  Management  Subsystem 

-  3M  for  Helo  Detachments 

-  PMS  Scheduling  &  Admin  Support 

-  Technical  Publication  Library 

-  Test  Equipment  Support 

Supply  and  Financial  Management  Subsystem 

-  Financial  Management 

-  Food  Services 

-  Retail  Operations 

-  Mobile  Logistic  Support  Force 

-  Supply  &  Financial  Reports 

Administration  Data  Management  Subsystem 

-  Disbursing  &  Personnel  Management 

-  Medical  and  Dental  Management 

-  Training  Management 
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Figure  4.6  Administrative  Data  Management  Subsystem 
D.  ADVANTAGES  OF  SNAP  II 

If  the  success  or  failure  of  a  shipboard  non-tactical 
computer1  system  is  measured  solely  in  meeting  primary  design 
goal,  then  SNAP  II  would  have  to  be  considered  an 
unqualified  success,  since  it  has  served  to  significantly 
reduce  the  administrative  burden  on  the  fleet.  As  the  SNAP 
II  system  is  further  developed  and  deployed  over  the  next 
several  years,  its  success  will  become  even  more  evident. 
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The  eight  points  discussed  below  present  some  of  the  more 
significant  advantages  of  the  SNAP  II  system. 

1.  Centeralized  Development.  SNAP  II  can  be  thought  of 

as  a.  centrally  managed,  geographically  distributed 
processing  system  designed  for  the  U.S.  Navy.  Each 
of  the  452  planned  nodes  of  this  distributed 
processing  system  will  be  located  on  different  Naval 
ships,  but  will  have  similar  processing 

configurations.  Under  this  view  of  the  system,  the 
functional  sponsors  and  the  fleet  commanders  act  as 
the  steering  committee,  making  system  management 
recommendations  to  the  CNO.  Therefore,  the  decisions 
on  how  to  manage  the  SNAP  II  system  take  on  a  more 
global,  priority  and  policy,  oriented  view,  than  a 
system  acquired  and  managed  solely  by  the  direction 
of  one  ship.  Goals  are  established  for  the  system  at 
a  high  level,  which  are  appropriate  to  the  scope  and 
cost  of  a  corporate  Information  System. 

2.  Standardized  System.  The  standardization  that  SNAP 
II  brings  the  Navy  will  be  far  reaching  in  nature.  A 
universal  system  such  as  SNAP  II,  results  in  many 
economies  of  scale  over  the  system's  life-cycle.  The 
training  requirements  for  users  is  minimized,  because 
every  system  is  functionally  the  same.  When  an 
individual  has  been  trained  on  the  SNAP  II  system, 
and  is  then  assigned  to  a  new  ship,  there  is  a  direct 
transfer  of  his  knowledge  and  skills.  Both  software 
and  hardware  can  be  managed  so  cost  of  changes  and 
modifications  are  minimized.  One  can  only  imagine  the 
chaos  that  would  result  if  a  major  change  in 
administrative  procedures  was  required,  and  every 
command  had  to  rewrite  their  application  programs  to 
incorporate  the  change.  With  a  "single  system"  you 
don't  reinvent  the  wheel  each  time  a  problem  must  be 
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solved.  Instead  the  SNAP  II  concept  provides  a 

single  point  for  the  resolution  of  all  problems. 
NAVMASSO  serves  in  this  capacity. 

3.  Improved  Logistic  Support.  The  logistics  of 

providing  world-wide  support  for  a  standardized 
system  like  SNAP  II  are  obviously  much  simpler  and 
more  cost  effective  than  attempting  to  provide  for  30 
or  40  different  systems.  Each  ship  will  carry  its  own 
repair  parts  and  expertise  in  maintaining  the  SNAP  II 
systems ,  yet  will  be  able  to  provide  assistance  to 
other  ships  if  needed.  Repair  parts  will  be  stocked 
in  depth  and  not  breadth,  i.e.  this  allows  the  supply 
system  to  procure  and  stock  parts  that  fit  all 
systems  vice  unique  parts  for  each  system.  This 
results  in  better  inventory  management  and  economies 
of  scope. 

4.  Increased  Accuracy.  The  increased  accuracy,  in 
reporting  parts  usage  for  both  corrective  arid 
preventive  shipboard  maintenance,  provides  the  Navy's 
material  managers  with  the  necessary  data  to  improve 
inventory  management.  As  a  direct  result  the  COSALs 
will  more  accurately  reflect  the  ship's  equipment 
configuration.  This  leads  to  better  supply  support 
and  consequently  improved  fleet  readiness, 

5.  A  Management  Tool.  The  manpower  savings  in  going 
from  a  manual  system  to  SNAP  II,  have  been 
significant.  While  SNAP  II  does  not  provide  many 
"bells  and  whistles",  it  does  provide  each  command 
with  the  basic  tools  needed  to  manage  shipboard 
administration,  without  requiring  the  assignment  of 
additional  crew  members  who  are  expert  in  the  system. 

6.  A  Control  Mechanism.  The  SNAP  II  system  has  had  a 
unifying  effect  on  the  entire  U.S  Navy.  By  providing 
a  "single  system"  for  all  the  ships,  policy  and 
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7. 


procedures  have  been  standardized.  No  longer  will 
there  be  the  "air"  Navy,  the  "surface"  Navy,  the 
"sub"  Navy,  and  the  "Atlantic  and  Facific"  Navies, 
all  with  different  rules  and  procedures  for 
maintaining  records  and  processing  reports.  Now 
there  will  be  only  one  system  . . .  SNAP  !  It  provides 
the  commanders  of  geographically  disbursed 
organizations  with  an  excellent  control  mechanism  to 
enforce  standards  and  implement  policy.  When  a  change 
has  to  be  made  in  administrative  procedures  it  needs 
only  be  developed  as  a  software  modification  and 
released  to  tne  fleet. 


Acquisition  Strategy.  One  main  advantage  of  the  SNAP 
II  acquisition  methodology  is  the  use  of  a  prime 
vendor  who  sub-contracts,  assembles,  and  integrates 
all  the  ADPE  components  and  systems  software.  This 
allows  the  Navy  to  use  one  point  of  contact  for 
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Contractor  Leverage.  The  use  of  a  small  contractor, 
such  as  SMA  or  Harris,  offers  a  distinct  advantage 
over  many  larger  contractors.  When  a  contract  such  as 
SNAP  II,  makes  up  a  significant  portion  of  their 
total  business,  they  tend  to  be  much  more  responsive 
to  the  unique  needs  of  the  Navy  in  scheduling, 
modifications  and  other  such  concerns. 


E.  DISADVANTAGES  OF  SNAP  II 

The  disadvantages  of  the  SNAP  II  system  can  be  argued 
from  the  point  of  view  of  the  Commanding  Officers  and  what 
it  provides  them  in  the  way  of  a  flexible  management  tool. 
Many  of  the  traditional  management  issues  of  shipboard 
command  involve  the  solving  of  dynamic,  unstructured 
problems,  that  are  not  always  supported  by  "canned  programs" 
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provided  by  standard,  management  information  system.  The 
points  that  follow  present  some  of  the  disadvantages  of  the 
SNAP  II  system  from  this  prospective. 

1.  System  Inflexibility.  The  application  software  for 
SNAP  II  is  designed  so  the  shipboard  user  cannot 
access  the  databases  with  locally  generated  programs. 
While  this  is  done  to  protect  the  integrity  of  the 
information  stored  in  SNAP  II,  it  incorporates 
inflexiblity  in  a  system  that  must  also  respond  to 
dynamic  changing  needs.  It  makes  little  sense  to 
limit  the  users  to  Basic,  when  Pascal  and  FORTAN  are 
also  supported  by  VOS.  Also,  without  a  dedicated 
SNAP  II  expert  assigned  to  each  ship,  it  is  unlikely 
the  fully  potential  of  the  system  will  ever  be 
realized . 

2.  User  Dependence.  A  growing  dependence  on  the  SNAP  II 

system  may  not  be  evident  until  a  major  casualty 
occurs  to  ey cnrU  ^  2, ^ couLd  i’s sul t 

from  anything  from  malicious  destruction  to  wartime 
damage.  This  dependency  is  a  huge  liability  because 
an  architecture  with  a  single  CPU  and  little  fault 
tolerance  has  been  chosen  for  SNAP  XI.  Unless  manual 
procedures  are  reheresed  and  practiced  on  a  routine 
basis,  the  ability  to  function  without  the  computer- 
may  be  quickly  lost.  Besides,  hard  copy  COSALs  and 
microfiche  listings  of  repair  parts,  as  well  as 
technical  manuals  must  still  be  maintained. 

3.  Lengthy  Implementation.  The  slow  development  and 
implementation  process  for  SNAP  II  creates  a 
situation  where  there  are  have's  and  have-not's. 
Those  ships  where  systems  have  been  installed  can 
exploit  its  usefulness  and  profit  from  improved 
management  of  people,  time  and  money,  while  those  not 
scheduled  to  receive  system  for  several  years  are 
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like  second  class  citizens  relegated  to  operating  in 
the  manual  mode.  This,  along  with  the  usual  problems 
with  application  backlogs  has  led  to  the 
proliferation  and  use  of  microcomputers  in  the  fleet. 
Some  applications  scheduled  for  implementation  on 
SNAP  II,  have  already  been  programmed  for  the 
stand-alone  microcomputers  and  are  meeting  user 
needs . 

4.  Classified  Data.  The  issue  of  handling  classified 
data  in  an  automated  environment  was  discussed 
earlier  in  this  chapter.  Since  a  good  deal  of 
shipboard  information  is  of  a  classified  nature,  the 
issue  must  be  addressed  in  meeting  the  information 
needs  of  the  ships.  At  the  present,  SNAP  II  does  not 
address  this  problem,  other  than  to  say  that 
classified  data  will  not  be  processed  on  the  system 
without  specific  approval  and  appropriate  security 
measures . 

5.  Contractor  Vulnerability.  As  a  result  of  the 

acquisition  process,  SNAP  II  is  being  integrated  and 
provided  by  a  small  company  whose  primary  business  is 
that  Navy  specific  contract.  Also,  the  computer 
hardware  comes  from  a  company  whose  computers  are 
primarily  used  by  the  Navy.  This  results  in  a 
situation  where  the  government  almost  has  to 

guarantee  the  success  and  continuance  of  these 
companies,  to  maintain  the  viability  of  the  SNAP  II 
systems.  If  they  were  larger  <  -  porations  with 
established  track  records  for  pe'  ■  voce,  the  risk 
of  them  closing  their  doors  and  c  out  of  business 

would  be  greatly  reduced.  Once  r  -  -  „ I  is  in  place, 
users  will  grow  to  depend  on  the  system  and  the 
information  that  it  provides.  The  Navy  will  not  be 
able  to  afford  the  disruption  and  expense  of 
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developing  another  system.  Fortunately,  the 
application  software  has  been  developed  so  that  it 
can  be  transported  to  other  hardware  systems. 

6.  Increasing  system  scope.  Since  new  capabilities  are 
often  added  to  computer  systems  under  the  guise  of 
software  maintenance,  the  scope  and  complexity  of  the 
systems  are  constantly  increasing.  This  situation  is 
no  different  with  SNAP,  causing  the  programs  to  look 
as  though  they  are  growing  without  bounds  as  the 
maintenance  tail  of  the  life-cycle  curve  continues  to 
widen,  giving  the  perception  of  poor  management.  This 
makes  it  extremely  difficult  for  those  who  must  argue 
for  funding  the  SNAP  programs 

F.  CONCLUSIONS 

The  SNAP  systems  have  been  developed  as  a  tools  to  make 
better  use  of  available  shipboard  manpower,  to  increase  the 
accuracy  of  the  information  used  in  managing  the  Navy,  and 
improve  the  quality  and  level  of  support  to  the  fleet.  These 
are  issues  that  relate  to  the  readiness  of  the  U.S.  Navy  in 
meeting  its  commitments  and  in  fulfilling  its  mission.  The 
research,  planning  and  development  that  was  completed  before 
SNAP  II 's  implementation  have  led  to  its  success  in  meeting 
these  goals. 

The  philosophy  of  using  a  "single  system"  to  meet  the 
information  and  administration  management  needs  of  the  Navy 
provides  many  interesting  results.  Not  only  are  the  systems 
life-cycle  costs  controlled,  but  also  almost  every  aspect  of 
providing  logistics,  training,  and  managing  operations,  are 
simplified.  An  additional  and  important  feature  provided  by 
the  "single  system"  concept  is  that  of  control.  The 
standardization  of  procedures  and  policy,  throughout  the 
Navy  as  a  result  of  SNAP  I  and  SNAP  II,  could  never  have 
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been  realized  under  a  less  centrally  developed  and  managed 
system.  Once  fully  implemented  in  the  fleet,  SNAP  II  will 
provide  a  mechanism  of  control  never  before  possible  under 
the  manual  system. 

The  primary  risk  inherent  in  systems  like  SNAP  I  and 
SNAP  II,  is  the  users  growing  reliance  on  the  information 
and  data  stored  on  the  computers.  In  a  war  time  environment 
it  is  likely  that  there  will  be  periods  of  time  when  the 
crew  has  to  function  without  the  SNAP  computer  system. 
Therefore,  the  capability  to  operate  in  a  manual  mode  must 
be  maintained  if  that,  risk  is  to  be  minimized.  While  the  use 
of  a  system  with  a  single  CPU  may  make  some  sense  in  the 
business  world,  it  poses  some  strategic  problems  to  a  war 
ship  that  is  geographically  separated  and  must  rely  on  the 
information  stored  in  the  database. 


Finally,  while  the  acquisition  process  of  major  systems 
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the  government  arena.  When  a  contract  is  bid  on  a  lowest 


cost  basis,  you  get  what  you  pay  for.  The  only  mechanism  to 
ensure  that  the  system  provides  product  that  is  needed,  is 
through  the  accurate  and  specific  design  specifications. 
This  is  where  the  prototyping  of  the  makes  such  a 
difference.  Get  the  requirements  "right"  before  contracting, 
and  then  stick  with  the  specifications  where  they  make 
sense.  The  objective  must  be  in  "getting  the  right 
system... and  getting  the  system  right."  [Ref.  91] 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  systems  discussed  in  this  thesis  have  illuminated  a 
spectrum  of  technical  problems  and  managerial  issues  that 
should  be  addressed  before  introducing  non-tactical 
computers  into  the  shipboard  environment.  For  example,  the 
Perq  minicomputers  suffered  many  technical  problems  on  board 
the  U.S.S.  Carl  Vinson,  because  the  hardware  was  neither 
designed  nor  specifically  ruggeaized  for  the  oftentimes 
harsh  shipboard  environment  it  had  to  operate  in.  If  the 
operational  environment  had  been  thoroughly  examined  before 
installation  of  the  Perq  computers,  then  different  hardware 
might  have  been  selected,  or  at  least  appropriate  protective 
devices  can  be  installed  installed  that  would  have  minimized 
some  of  the  equipment  casualties  that  were  experienced 
during  the  1983  cruise.  SNAP  II,  on  the  other  hand, 
experienced  several  technical  problems  because  design 
specif  cations  were  initially  not  adhered  to  i.e.  size, 
weight,  etc.,  or  because  they  were  changed  to  match 
equipment  capabilities  e.g.  response  time.  Some  of  the 
managerial  issues  that  should  be  considered  if  an 
implementation  is  to  be  successful  include  manning, 
security,  applications,  and  the  speed  with  which  the  system 
should  be  implemented,  to  name  just  a  few. 

Both  the  Perq  and  WANG  systems,  as  installed  on  the 
U.S.S.  Carl  Vinson,  demonstrate  some  pitfalls  that  can 
occur  if  implementation  is  done  too  fast  and  without  the 
benefit  of  a  thorough  requirements  analysis.  In  each  case 
the  wrong  machines  were  initially  installed.  The  Ferq's  were 
not  hardy  enough,  and  except  for  the  VS- 100,  the  WANGs  were 
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not  large  enough.  The  SNAP  system  on  the  other  hand,  has 
suffered  from  a  long,  drawn-out  Implementation  process, 
primarily  because  of  the  extensive  procurement  process 
required  for  compliance  with  public  law  89-  306  regulations, 
often  called  the  Brook's  Bill.  While  the  conceptual  idea  for 
SNAP  was  approved  in  1978,  only  56  of  452  planned 
implementations  were  installed  as  of  October  1984.  This  slow 
process  results  in  the  SNAP  design  being  constantly  altered 
or  adjusted  to  take  advantage  of  new  technology,  or  to 
correct  deficiencies  in  the  original  design.  This  means  the 
first  units  installed  will  ha /a  to  be  back-fitted  with  these 
design  or  operational  changes  to  maintain  system 
standardization. 

Although  the  Ferq  computers  suffered  from  equipment 
reliability  problems,  they  did  demonstrate  the  advantage  of 
having  a  distributed  processing  capability.  Despite 
casualties  to  several  of  the  Perq  computers  during  the 
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completely  disabled  because  of  equipment  redundancy.  This 
redundancy  is  not  provided  for  on  either  the  WANG  VS- 100  or 
Harris  SNAP  II  systems,  because  of  their  single  CPU 
architecture.  The  risk  of  total  system  failure  due  to 
electrical  power  problems,  malicious  damage,  or  sabotage  is 
therefore  much  higher  in  these  systems  than  on  the  network 
of  Perqs. 

The  term  non-tactical  is  misleading,  because  it  connotes 
a  system  of  secondary  importance.  For  shipboard  non-tactical 
automation  nothing  could  be  farther  from  the  truth.  With 
applications  such  as  the  supply-maintenance  interface, 
intraship  communications,  and  general  word  and  data 
processing,  these  non-tactical  computers  are  becoming  more 
critical  to  the  everyday  operations  of  the  ship.  As  more 
applications  are  developed  for  these  non-tactical  computers, 
both  system  dependency  and  the  penalty  for  system  failure 
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increase  in  magnitude.  Along  with  these  increased 
applications  the  risk  of  a  sudden  and  devastating  capacity 
crunch  becomes  much  higher.  This  is  what  happened  on  the 
smaller  WANG  systems  before  the  VS-100  was  installed.  The 
Wang  System-20,  System-30,  and  VS-80  were  too  small  to 
handle  the  ever  increasing  demands  placed  on  them  by  the 
ship's  users.  Whenever  a  new  system  was  installed  it  would 
reach  its  capacity  limit,  resulting  in  a  discernible 
slow-down  and  the  inability  to  satisfy  the  many  new 
applications  that  were  being  developed  by  shipboard  users. 

Another  area  that  must  be  closely  looked  at  is 
life-cycle  cost.  This  includes  the  original  cost  of  the 
equipment,  as  well  as  operating  and  maintenance  cost  for  the 
life  of  the  system.  Oftentimes,  the  original  equipment  cost 
is  the  least  expensive  part  of  the  life-cycle  cost.  For 
example,  a  WANG  VS-100  super  minicomputer  with  8  input, 
output  processor  interfaces,  a  16  port  serial  I/O  processor 
controller,  a  macroassembler,  and  one  archive  processor  is 
listed  for  approximately  $72,000  on  current  Federal  Supply 
Contract  schedules.  Other  vendors  can  supply  comparable 
equipment  at  similar  prices.  Of  course,  when  you  start 
adding  the  cost  for  hard  disk  memory,  terminals,  printers 
and  other  peripheral  equipments,  the  price  rapidly 
increases.  The  majority  of  an  information  systems  cost  is 
spread  throughout  'its  lifecycle  as  maintenance,  repair 
parts,  wages  for  operating  personnel,  and  software.  These 
costs  can  exceed  the  original  purchase  price  within  a  short 
time.  Although  the  WANG  was  specifically  used  in  this 
example,  these  cost  hold  true  for  any  computer  system. 

While  the  WANG  installation  on  the  U.S.S.  Carl  Vinson 
has  proven  the  feasibility  of  using  off-the-shelf, 
commercial  computer  equipment  in  a  shipboard  environment, 
the  Perq  has  demonstrated  the  necessity  for  choosing  the 
equipment  wisely.  This  equipment  should  include  overload 
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protection,  line  protection,  and  the  availability  to  operate 
at  different  ambient  temperatures  if  a  suitable  controlled 
environment  cannot  be  provided. 

B .  RECOMMENDAT IONS 

1.  Before  developing  or  purchasing  a  non-tactical 

computer  system,  regardless  of  size,  a  cost/benefit 
analysis  should  be  conducted.  This  will  help  identify 
total  life-cycle  cost,  as  well  as  assist  in 

identifying  or  justifying  the  need  for  such  a  system. 

2.  A  requirements  analysis  should  be  conducted  before 
committing  to  a  system.  This  will  help  in  deciding 
whether  an  information  system  should  be  purchased, 
and  if  so  which  one. 

3.  Both  hardware  specifications  and  site  preparation 
must  be  well-thought  out  and  defined  before  actual 
procurement  of  a  system .  They  should  address 
appropriate  power  requirements  such  as  line  filters, 
overload  protection,  and  an  uninterruptable  power 
supply,  as  well  as  size  and  weight  constraints, 
special  environmental  requirements,  and  security  and 
safety  considerations  for  both  personnel  and 
equipment . 

4.  Where  available,  both  commercial  hardware  and 
software  should  be  procured  and  used. 

5.  The  user  should  drive  application  development 

whenever  possible.  Use  of  a  fourth  generation  type 
language  such  as  Nomad,  Focus,  or  similar  commercial 
products  allows  the  user  to  develop  his  own 

applications.  This  is  conducive  to  innovation,  while 
also  minimizing  costly  software  development. 

6.  Ensure  that  system  architecture  is  flexible  enough 
to  allow  for  growth  and  incorporation  of  new 
technology. 
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7. 


A  shipboard  non-tactical  computer  system  should  be 
developed  uader  the  same  philosophy  as  other  critical 
equipments  onboard  ship,  i.e.  redundancy.  One  way  to 
do  this  is  to  use  a  distributed  network  whenever 
possible . 

8.  To  encourage  user  innovation  the  system  should  have 
some  excess  capacity  that  can  be  used  for  locally 
developed  programs.  The  SNAP  concept  does  this,  but 
uses  the  basic  language  instead  of  a  more  flexible, 
more  user  friendly  language. 

While  these  recommendations  do  not  in  themselves 
guarantee  a  successful  system  implementation  of  a 
non-tactical  computer  system,  they  reflect  some  successful 
aspects  of  the  Perq,  WANG,  and  SNAP  II  systems,  which  should 
be  considered  when  designing  computer  systems  for  the  fleet. 
Research  programs  like  Perq/ZOG  and  commercial  systems  like 
the  WANG  have  a  definite  place  in  the  Navy,  and  should  be 
continued,  because  of  the  ingenious  and  innovative  ways  in 
which  they  are  used.  These  creative  ideas  can  then  be 
transfered  to  the  more  stanoardized  systems  like  SNAP.  As  we 
view  the  future,  we  must  continue  to  look  for  ways  to  use 
new  technology  to  increase  productivity  in  the  fleet. 
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SNAP  II  MANUFACTURERS  AND  VENDORS 


Device 

Manufacture 

CPU 

Harris 

Mass  Storage 

Winchester 

KVDTs 

Harris 

Prog  I/O  Channel 

IPOC 

WP  Printer 

NEC 

Line  Printer 

PRINTRONIX 

Display  Printer 

MPI 

Paper  Tape 

REMAX 

Card  Reader 

DOCUMENTATION 

Streaming  Tape 

CIPHER 

Floppy  Dsk  Drive 

INSTOR 

Vendor 

Harris 

Harris 

Harris 

Harris 

Bartlett  Associates 
PRINTRONICS 

Engineered  Control  Systems 

Harris 

Harris 

Harris 

Harris 
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ADM 

ADP 

ADS 

ADPE 

AI S 

APL 

CCOL 

CDA 

CIC 

CII 

CMU 

CNO 

COSAL 

CPU 

CRT 

CSMP 

DARPA 

DCA 

DM5 

DS 

ET 

FMS 


GLOSSARY  OF  TERMS 

Administrative  Data  Management  Subsystem 

Automated  Data  Processing 

Automated  Data  System 

Automated  Data  Processing  Equipment 

Automated  Information  System 

Allowance  Part  Lists 


Compartment  Check  Off  List 
Central  Design  Activity 
Combat  Information  Center 
Computer  Integrated  Instruction 
Carnegie-Mellon  University 
Chief  of  Naval  Operation 
Consolidated  Ships  Allowance  Listing 
Central  Procession  Unit 
Cathode  Ray  Tube 

Coordinated  Ship's  Maintenance  Project 


Defense  Advanced  Research  Agency 
Damage  Control  Assistant 
Data  Management  System 
Data  Systems  technicians 


Electronic  Technicians 


Federated  Management  System 
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GSA 


General  Services  Administration 


I/O 

Input/Output 

KVDT 

Keyboard  Video  Display  Terminals 

MAG 

MB 

MENS 

MIS 

MPDS 

Marine  Air  Group 

Megabyte 

Mission  Element  Needs  Statement 

Management  Information  System 

Message  Processing  Distribution  System 

NAVMASSO 

nmnn/-i 

ANr 

Navy  Management  Support  Systems  Office 

in d  v  d x  rci.  auuuci  i\csedL  ^11  euma  u6V«siOpui«ii^ 

OMMS 

ONR 

ORSE 

Organizational  Maintenance  Management  Subsystem 

Office  of  Naval  Research 

Operational  Readiness  System  Evaluation 

PC 

PLAD 

PROM IS 

PRP 

PQS 

Professional  Computer 

Plain  Language  Address 

Problem  Oriented  Medical  Information  System 

Personnel  Reliability  Program 

Personnel  Qualification  Standard 

RAM 

RT 

Random  Access  Memory 

Real-Time 

SBA 

SDS 

SHIPALTS 

Small  Business  Administration 

Shipboard  Data  System 

Ship  Alterations 
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SFM 

SMA 

SMS 

SNAP 

SORM 

SOW 

SPICE 

SSTG 

STAS 

UPS 

VAC 

VISP 

VOS 

ZED 


Supply  and  Pii  mcialManagement  Subsystem 

Systems  Management  American 

System  Management  Subsystem 

Shipboard  Non-tactical  ADP  Program 

Ship' s  Organization  and  Regulations  Manual 

Statement  of  Work 

Scientific  Personal  Integrated  Computing  Environment 
Ship's  Service  Turbo  Generators 
Shipboard  Training  Administration  System 

Uninterruptible  Power  Supply 


Volts  Alternating  Current 
VOS  Indexed  Sequential  Package 
Vulcan  Operating  System 

ZOG  edit 
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